python-midi
python-midi copied to clipboard
vishnubob
Python 3
Can't speak for @vishnubob but I suspect no one has plans.The built-in 2to3 converter might do a decent job though, considering how small and straightforward the codebase is.
Unfortunately, using 2to3 doesn't exactly make everything work. The program has a problem in the events.py file: ValueError: 'pitch' in slots conflicts with class variable (line 112ish).
A quick google turns up another github page with a guy saying, "The problem is happening because in Python 2.x if you defined slots and after that defined a property with the same name the slots descriptor was replaced silently. In Python 3.x this isn't allowed anymore."
Unfortunately, this is beyond my understanding of the language and so I can't fix it. There may be more 2.x / 3.x issues too.
Hi jsphweid, thanks for your message. I guess this might require a metaclass to solve, or getting rid of slots. I use slots because I wanted each individual MIDI event object to have as minimal of a memory footprint as possible, but maybe this unnecessary? If I get sometime next week, I will try to implement a new branch with 3.0 compatibility.
My brother and I started removing them and it would run parts with no errors but it seems there were other issues. Can't remember. But it might not be that far off at all.
Ok I'm reading up on this too and I'm not 100% sure slots work with
property()... potentially the latter overrides the former. Objects might
need a __dict__ in order to have getter and setter methods associated
with them and hence couldn't have slots? I'm not well-versed in the details
of python data structures though.
There are also quite a few issues with string/byte file IO :/. Not to mention some old conventions; use of xrange, the old form of exception raising (raise ValueError, "msg"), old metaclass syntax (one instance), non-relative importing :/
Downloading from feature/python3 and installing manually with setup.py still throws error, guess the compatibility was implemented only for linux ? what about other platforms ?
Right now it's in a holding pattern until I can find some time from work to focus on my open source projects. I'm also interested in working with volunteers.
I looked into Python 3 compatibility without realizing the Python3 branch at first. While I appreciate the effort that already went into the Python3 branch I think it forks away from the master branch too far - needlessly. Many of the changes are also compatible with Python 2 and should be done in the master branch. I especially dislike the reformated code pieces which are semantically unchanged but will make applying future patches much more difficult.
If there is any interest I can create a set of patches that ports most of those changes into the master branch. It should be possible to make the master branch compatible with both Python2 and Python3 if some hacks (and usage of the "future" module) are acceptable. Otherwise it should be possible to come up with a new Python3 branch with very few, very small patches that address specific Python2 vs Python3 incompatibilities only.
One thing that would probably help would be to use the six module, which does a bunch to make the pythons the same.
Having a feature/python3 branch which is inferior to what's hidden in PR #130 (among numerous half-attempt PRs) is causing a lot of confusion and duplicate efforts.
@vishnubob please close the cruft PR's and defunct branch.
