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 #136

Open
2 of 12 tasks
CRImier opened this issue Nov 21, 2018 · 9 comments
Open
2 of 12 tasks

Python 3 #136

CRImier opened this issue Nov 21, 2018 · 9 comments

Comments

@CRImier
Copy link
Member

CRImier commented Nov 21, 2018

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.

  • For now, changing all scripts to explicitly mention Python 2 (i.e. /usr/bin/env python to /usr/bin/env python2` in shell scripts)
  • Use six to switch as much code as possible while keeping backwards compatibility
    • isinstance checks
    • various imports
    • keys(), values() and items() calls
    • range() calls
    • functools.wraps decorations
    • filter calls
    • For each place where it doesn't seem possible to keep backwards compatibility, post the details here for a discussion
  • Make all the tests pass with Python 3
  • Investigate any libraries in requirements.txt that don't work with Python 3, report here
  • Check if all of our helper scripts will still work
  • Go through the input and output drivers, see which ones might not work with Py3, add warnings (i.e. logging.warning) to drivers that aren't yet tested
    • rule of thumb: anything that needs bit manipulations will have to be tested on real hardware, so will need a warning until then
@LouisPi
Copy link
Collaborator

LouisPi commented Nov 22, 2018

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.

@LouisPi
Copy link
Collaborator

LouisPi commented Nov 22, 2018

The first task looks easy enough for me to do tomorrow and maybe the second one too.

@CRImier
Copy link
Member Author

CRImier commented Nov 22, 2018

Thank you! Rr: unpaddedbase64 - we're not aiming for Python 3.2 compatibility, then =D jsonrpclib is mainly used by the pomodoro app (though it is supposed to be usable by user-written apps, too, I just never got around to writing a tutorial). smspdu is used by the current "Phone" app, which we'll deprecate really soon.

@CRImier
Copy link
Member Author

CRImier commented Nov 22, 2018

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 ui/tests (i.e. python test_menu.py).

@LouisPi
Copy link
Collaborator

LouisPi commented Nov 22, 2018

Ah okay.

@LouisPi
Copy link
Collaborator

LouisPi commented Dec 1, 2018

Are we supporting versions older than Python 2.7 as well? The Python docs state

While you can make Python 2.5 work with Python 3, it is much easier if you only have to work with Python 2.7

and also

you should aim for only supporting Python 2.7. Python 2.6 is no longer freely supported and thus is not receiving bugfixes. This means you will have to work around any issues you come across with Python 2.6

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,
Louis P

Edit - source for the quotes is here - https://docs.python.org/3/howto/pyporting.html

@CRImier
Copy link
Member Author

CRImier commented Dec 1, 2018

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 six, since six is a 2-to-3 compatibility library and doesn't really concern 2.6 as such. I see it mentioned in the docs where 2.6 is involved, but the relationship is not clear to me.

@LouisPi
Copy link
Collaborator

LouisPi commented Dec 1, 2018

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 .

@CRImier
Copy link
Member Author

CRImier commented Jan 10, 2024

Port started in devel branch with ae12f2c

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

No branches or pull requests

2 participants