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:
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.