[mb-devel] The future of python-musicbrainz2
jjjordan at cal.berkeley.edu
Sun Mar 14 00:48:17 UTC 2010
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.
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
> 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
>> 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.
> 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 .
>>  http://unmaintainable.wordpress.com/2010/03/13/future-of-python-musicbrainz2/
>> MusicBrainz-devel mailing list
>> MusicBrainz-devel at lists.musicbrainz.org
> MusicBrainz-devel mailing list
> MusicBrainz-devel at lists.musicbrainz.org
More information about the MusicBrainz-devel