Python 3 is the future. Every day, it seems, I come across a Python 3 feature that I wish I could use in beets (to name a few: lru_cache, yield from, working namespace packages, and my own patch, aliases in argparse). And with the release of Python 3.3 imminent, I think the age of widespread adoption is nearly here.

So when will beets move to Python 3? As with so many other projects, beets’ transition is blocked on its dependencies. Before we can make the jump, all of these libraries, which are required by beets “core” or its included plugins, need to go first:

  • Mutagen, the audio tag manipulation library. This is beets’ main barrier—Mutagen is an integral part of beets; it will be complex to port due to its Unicode-related logic; and I have no intention of switching to a different library (TagLib being the only viable alternative I know of).
  • Munkres, a bipartite matching solver. Should be a straightforward port.
  • python-musicbrainz-ngs, bindings to the MusicBrainz API. I and the other contributors to this library have been moving toward Python 3 compatibility for some time.
  • pyacoustid and audioread support beets’ acoustic fingerprinting plugin. I wrote both of these libraries and should be able to port them with minimal effort.
  • python-gstreamer is used by the BPD plugin and the current incarnation of the ReplayGain plugin. I believe that forward-compatibility just entails moving to Gstreamer 1.0 and PyGI.
  • Flask, the basis of the Web interface plugin, currently does not support Python 3. The author, Armin Ronacher, has been critical of some changes in Python 3, especially with regard to Web applications and frameworks. So Armin may need to help fix Python itself first before Flask and Werkzeug become 3-compatible.

Some dependencies (Unidecode, pyLast, Colorama, and Bluelet) are already compatible.

The principal blockers, then, are Mutagen and Flask. The remaining dependencies either have clear upgrade paths or are simple enough that I should be able to contribute compatibility patches back to them. But Mutagen and Flask are too complex (and popular) to make a unilateral porting effort feasible. This means that, if you want to help bring beets to Python 3, the best place to start is with porting Mutagen.

In the meantime, I’m writing beets to be as forward-compatible as possible. An eventual port will still be a headache—due to the need to explicitly manage a distinction between Unicode and raw-bytes path names—but I’m excited to do the work as soon as it’s feasible.

When the leap does eventually happen, I plan to leave Python 2 behind entirely. Beets is not widely used as a library (Headphones is the only dependent I’m aware of) and most Linux distributions these days ship with some version of Python 3. Going 3-exclusive will make maintaining beets’ bytes/Unicode distinction much simpler.

While beets will almost certainly not make the Python 3 leap until after 1.0, that day is not as distant as it might seem at first.

This post was published on September 9, 2012. Have comments or questions? Post on the discussion board, toot at @beets@fosstodon.org, or discuss on Hacker News.

Fork me on GitHub