Version 0.91 of TagPy is out
Submitted by inducer on Mon, 26/06/2006 - 23:33
I’ve just released version 0.91 of TagPy. Besides some minor fixes, the biggest change is that you don’t say any more
tag.setArtist("Fat Boy Slim")
Instead, the (IMO) much more pythonic
tag.artist = "Fat Boy Slim"
is now where it’s at. Reading these attributes (and just these) is also changed from tag.artist() to tag.artist. I repeat, this only affects
Tag.titleTag.artistTag.albumTag.genreTag.yearTag.trackAudioProperties.lengthAudioProperties.bitrateAudioProperties.sampleRateAudioProperties.channels
Since these are so frequent, I saw a compelling reason to change them. Everything else in the API will remain as close as possible to TagLib’s C++ conventions.
Sorry for the source-incompatible change, it will not happen again.
Enjoy.
All content bearing the “inducer” username is hereby licensed under
Creative Commons Attribution-Share Alike 2.5 License.
For the purposes of German law: I am not repsonsible for material on pages linked to from this site.
Thanks for sharing this evansheadnsw
Hi!
After reading more carefully the TagLib and the ID3 docs, I agree that the dictionary-like interface wouldn’t be the “perfect solution” I imagined it would be. Like you mentionned, each tagging standard has some idiosyncracies. For me, some of the main problems are:
(I didn’t look the APE tags). A dictionary that would support all these differences would be possible (it is one of the way to access the tags in TagLib) but not very elegant.
I still think that, for basic tags, the dictionary is better than the properties (because, deep down, tags are just a set of key-value entries), but I guess it is just a matter of taste. :) Of course, if one of your design goal for this project is to stay close to the original TagLib API, then, yes, properties are the right way to replace getters and setters in Python.
Nice discussing with you. Keep up the good work! :yes:
Slach
This is useful stuff, even though I’m just learning programming, thanks for sharing though! evansheadnsw
Hi!
I am looking for a library for reading mp3 and ogg tags in python and I stumbled upon your page. I am about to test TagPy.
About the changes, I think that the more “pythonic” way to access the tags would be to have a dictionary-like interface:
tag[‘artist’] = ‘Fat Boy Slim’
by defining the getitem() method and some other methods on the tag class…
(see http://docs.python.org/ref/sequence-types.html for more info).
By doing this, you have a common interface for every tag and you can also make the key (ie, the tag name) case-insensitive.
Slach
I disagree:
This does not and should not cover all tags, as (unfortunately) each tagging standard has its own idiosyncracies past these basic tags. In ID3, you get to meddle with frames, Ogg has the (fantastically simple) Key-Value map, and APE has something still different. Glossing over these differences would be folly.
Past that, TagPy does not mean to invent its own API. In particular, I don’t mean to write documentation for it at all. It should be sufficiently clear from Scott Wheeler’s documentation what the Python API will look like. It just happens that the “right” way to wrap getXXX() and setXXX() calls in Python is to have properties and not separate methods. I got this wrong in the first release.
I appreciate your comment, though. }:) Feel free to refute my views.
Post new comment