[mb-devel] The future of python-musicbrainz2

[JJ Jordan]

As a user of python-musicbrainz2 and a minor contributor
(releasegroups), I feel I can chime in here...

I don't know enough about the NGS to render an accurate judgment, but I
feel like your design is good and you should stick with what works. 
However, as I was working on the code it occurred to me that much of the
data model and serialization code could be generated.  I don't know how
you feel about generated code, but I think this would be a good
application of it.  It's at least worth some consideration.  (this
doesn't change the design, it just adds a meta-level to some pieces)

And two responses to points you make on your blog post:

A selfish consideration on my part: my project can't use Python 3.  It's
not that I'm unwilling, but that my project also uses Django, which is
not yet Python 3 compatible.  This would prevent me from an upgrade to
NGS because it also happens to require 3, at least until Django catches up.

MbXmlWriter has immense value for testing purposes.  I mock out
IWebService, and employ MbXmlParser, Metadata, and MbXmlWriter to
simulate musicbrainz interaction in unit tests.  It would be a shame to
see it go (but I'll move on :-)).

For the record, I'm glad someone is running with this.  Python
extensions seem to be falling out of favor from my vantagepoint, and I
was afraid this was going to drop off too.  I'm pleased to see that's
not the case.

Thanks,
John Jordan

On 3/13/2010 3:48 PM, Alastair Porter wrote:
> I've been thinking about this a bit as well, since I have a few python
> projects that use musicbrainz data and would like to see them using NGS
> too.
>
> I'm happy to give a hand rewriting/porting the library.  A few comments
> on your points:
>
>   
>> Use Python 3 (it won’t go away, so someone has to start, right?)
>>     
> I think there's still a very significant portion of apps using python
> 2.x. How about using 2.6 with as many of the 3.0 syntax as possible?
> That way the final step to saying "This is python3" should be quite
> trivial
>   
>> Make it more pythonic where possible (naming conventions?)
>> Remove rarely used cruft (MbXmlWriter, I’m looking at you!)
>> Keep the amount and quality of documentation
>> Write more test cases (64 test cases isn’t much)
>>     
> All these points sound good
>   
>> Use a DVCS (maybe git, but preferably Mercurial)
>>     
> The mbserver guys have moved onto git so it might be worth considering
> keeping consistency in this regard (I'm a git fan too) but any DVCS
> would be better than svn IMO.
>
> Alastair
>
>
> On Sat, 2010-03-13 at 15:19 +0100, Matthias Friedrich wrote:
>   
>> Hi all,
>>
>> I haven't followed MB developments in quite a while, but it looks to
>> me that NGS is getting closer. This means web service changes and as a
>> result changes in client libraries.
>>
>> Right now I'm pondering whether I should rewrite the whole thing for
>> NGS or leave it to someone else (question is, who would that be?).
>> Most of the original design (modulo the MB data model) still looks OK
>> to me, but it would be a nice opportunity to revisit design and
>> technology choices.
>>
>> Is there something that should be done differently this time? Any
>> ideas? Feel free to comment here or on my blog [1].
>>
>> Cheers,
>>   Matthias
>>
>> [1] http://unmaintainable.wordpress.com/2010/03/13/future-of-python-musicbrainz2/
>>
>> _______________________________________________
>> MusicBrainz-devel mailing list
>> MusicBrainz-devel at lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
>>     
>
>
> _______________________________________________
> MusicBrainz-devel mailing list
> MusicBrainz-devel at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel