-
Notifications
You must be signed in to change notification settings - Fork 19
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 #136
Comments
Smspdu doesn't list support for Python3, jsonrpclib doesn't support Python3 although work has been done here towards Python3 compatibility (joshmarshall/jsonrpclib#59) and unpaddedbase64 does not support Python 3.2. All other libraries in requirements.txt list support for Python 3. |
The first task looks easy enough for me to do tomorrow and maybe the second one too. |
Thank you! Rr: |
The problem with relative imports that I discovered today - Python 2 doesn't handle all of them as well as it should, complaining like "Attempted relative import in non-package". If that doesn't happen normally, it might still happen when you, say, run tests in |
Ah okay. |
Are we supporting versions older than Python 2.7 as well? The Python docs state
and also
I think there is a clear message in the Python docs there. To put it into context Raspbian has Python 2.7.13 installed and has supported Python 2.7 since it first existed AFAIK considering Python 2.7 was released almost 2 years before the first Raspberry Pi was released. I see no reason why other operating systems for the Pi won't have Python 2.7 installed. If we did go down the course of supporting Python 2.7 and Python 3, it would save the need for using six and as the Python docs suggest, make it easier to port the code to Python 3. Of course the choice is yours and this is just my opinion after doing some research. Thanks, Edit - source for the quotes is here - https://docs.python.org/3/howto/pyporting.html |
I haven't aimed for Python 2.6/2.5 compatibility in the past, and I'm not sure it makes sense to do so now - our targets (Raspbian Stretch) have long abandoned 2.6/2.5. So, let's stick to 2.7 =) However, I don't see how it'd save the need for using |
Not really my speciality subject (I just did some searching) but it seems that there are supposedly 'easier' ways to keep code working with Python 2.7 and Python 3. That is according to the official docs. However, many other websites seem to recommend using six as well. Maybe I concentrated too much on the official docs. Maybe this link could be a useful reference - http://python-future.org/compatible_idioms.html . |
Port started in |
We need to ensure Python 3 compatibility - soon, Python 2 will no longer be the default Python interpreter, and we don't yet support Python 3. There are problems associated with switching, of course - a lot of our code doesn't support Python 3, and some of it (mainly low-level oriented) doesn't support it in a major way. We could migrate with
2to3
, but it's nasty in the way that it's an one-way switch, and it's certain we'll have a Python 2 userbase for a long time./usr/bin/env python
to /usr/bin/env python2` in shell scripts)six
to switch as much code as possible while keeping backwards compatibilityisinstance
checkskeys()
,values()
anditems()
callsrange()
callsfunctools.wraps
decorationsfilter
callsrequirements.txt
that don't work with Python 3, report hereThe text was updated successfully, but these errors were encountered: