Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python 3 #35

Open
phaethon opened this issue Apr 29, 2014 · 16 comments
Open

Python 3 #35

phaethon opened this issue Apr 29, 2014 · 16 comments
Labels

Comments

@phaethon
Copy link

Any plans on Python 3 compatibility?

@tdhsmith
Copy link
Contributor

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.

@jsphweid
Copy link

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.

@vishnubob
Copy link
Owner

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.

@jsphweid
Copy link

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.

@tdhsmith
Copy link
Contributor

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.

@Mause
Copy link

Mause commented Jan 26, 2015

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

@paultag
Copy link

paultag commented Mar 3, 2015

👍 to this bug :(

@vishnubob vishnubob added the Bug label Aug 23, 2015
@vishnubob
Copy link
Owner

Thanks to a contributor, there is now a python3 test branch.

@Anmol-Singh-Jaggi
Copy link

What is the current status ?

@GeorgeTailor
Copy link

GeorgeTailor commented Aug 19, 2016

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 ?

@carlthome
Copy link

Status?

@vishnubob
Copy link
Owner

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.

@florianfesti
Copy link

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.

@vishnubob
Copy link
Owner

by all means.

@oscardssmith
Copy link

One thing that would probably help would be to use the six module, which does a bunch to make the pythons the same.

@belm0
Copy link

belm0 commented Jun 5, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests