Comment 1 by Georges Dubus, May 18, 2011
One more thing : in python 3, the caught exception is deleted in the except block, so I explicitly copied it. ( http://docs.python.org/dev/py3k/whatsnew/3.0.html#changes-to-exceptio ns )
Comment 2 by Helmling, Nov 5, 2011
Hi, FYI I have created a python3 port of mpd.py some time ago, which works flawlessly for me. It can be found here: https://github.com/supermihi/littlehelpers/blob/master/mpd.py At a first glance, there don't seem to be too much differences to the current version; I will try to incorporate the changes as soon as I find some time.
Comment 3 by Helmling, Nov 5, 2011
Hi, FYI I have created a python3 port of mpd.py some time ago, which works flawlessly for me. It can be found here: https://github.com/supermihi/littlehelpers/blob/master/mpd.py At a first glance, there don't seem to be too much differences to the current version; I will try to incorporate the changes as soon as I find some time.
Comment 4 by Jörg Thalheim, Feb 17, 2012
https://github.com/Mic92/python-mpd I add python3 support, while keeping compatibility with python2.6 and python2.7. You can convince yourself by running the unittests: python test.py I also add some new mpd commands and a public api to extend the Protocol of python-mpd in the future. Me and some other guys need this features for our projects (I currently port sonata to py3 and gtk3) So please accept this changes!
Comment 5 by Jörg Thalheim, Feb 26, 2012
Because I don't get any feedback, I will start to include my own copy of python-mpd in this and all other projects. So in future version sonata will not depend any more on python-mpd.
Comment 6 by Helmling, Feb 27, 2012
I find it very interesting that you managed to support both python versions with a single code version; in my py3 port, I didn't bother with backwards compatibility. :-) I'd really like to see your patch applied to the "official" python-mpd version, because sonata surely is not the only program for which it is useful (e.g. I am working on a different player also written in py3k :-) ). It seems pointless to me if several versions have to be managed in parallel...
Comment 7 by Jörg Thalheim, Feb 27, 2012
Otherwise we could also fork. The debian maintainer of this package is interested in it as well.
Comment 8 by Helmling, Feb 27, 2012
Well, then why not just propose your github page to the debian maint? Since the changes against the official version seem to be rather small and the unittests pass, it should not be to much of an issue to switch to the fork in debian (and possibly other distributions as well). I in any case volunteer for testing the module in my application!
Comment 9 by Jörg Thalheim, Feb 27, 2012
I would need a new name for this to avoid conflicts and confusion.
Comment 10 by Helmling, Mar 5, 2012
Well I'm afraid there's not too much to choose from here. :-) python-mpd and pympd are already assigned. mpd-python? MPyD? pympdclient? Something completely different? ...
Comment 11 by Jörg Thalheim, Mar 8, 2012
Or just python-mpd2. I just don't want to discuss on each distro, if say want to take my package or not.
Comment 12 by Helmling, Mar 12, 2012
Yes, I understand that point. python-mpd2 should be fine (or even python-mpd-fork :-) ). One other option would be to contact the author of this page directly via email and ask if he lets you continue the official maintainance of the project; he doesn't seem to have too much interest in it anymore.
Comment 13 by Geoff jack, Mar 12, 2012
We already tried to contact him to avoid to fork the project, but he remains unresponsive :( Forking is an extra work for maintainers/developers and confusing for users, I'd prefer not having to deal with a fork (from my user and packager point of view).
Comment 16 by J. Alexander Treuman, Mar 19, 2012
Sorry I haven't replied to this sooner. I have been seeing the posts, I've just had a lot of shit going on, and until now I haven't had much to add beyond "I'm too busy for python-mpd." :P Basically, I don't see myself doing much with python-mpd anytime soon. However, there's no one I really trust enough to hand over development to. At the same time, I'm also reluctant to give my blessings to a fork. There's still a lot I want to do with python-mpd, and I DO want to get to it someday, I just don't know when that'll be, or if I'll even have the interest when the time comes. But after talking to kaliko on IRC today, I've decided what to do about all that. At some point in the next couple of months, I'm going to release a "final" version of python-mpd, which will basically be the current version, but with support for python3. I say "final" because it may very well be my last release, although I do reserve the right to continue its development in the future. In the meantime, continue with development of the fork. Then users (even of python3) can choose between the original, knowing it may become stale, or the fork, knowing it won't be supported by me. That way I still have the opportunity to continue development before losing all of the current users, while still giving the fork a chance to thrive. And if the fork overtakes the original before I pick up development again, I'll probably just give up and admit defeat. ;) Also, when I release the "final" version, I'll try to publish all of the docs/examples/code/patches/emails that I haven't made public yet. I intended to integrate most of it eventually, I just never got around to it. I'll also try to write up a little roadmap of the direction I wanted the project to go in. That way maybe the fork can at least try to stick to what I had in mind. Right now, the only real complaint I have about the fork is the name. python-mpd2 makes it sound like it's newer/better in some way, when in reality it's currently just python-mpd with a few minor patches. And if the day comes that I do pick up development again, it may get to a point where the original surpasses the fork, making the naming scheme even more confusing. On the other hand, I don't really have a better idea. :P
Sign in to reply to this comment.
Reported by Georges Dubus, May 18, 2011