python-devel December 2014

python-devel@lists.fedoraproject.org

5 participants
3 discussions

Updated Python 3 migration tools and HOWTO guide
by Nick Coghlan 12 Dec '14

12 Dec '14

Brett Cannon recently published an updated version of the Python 3 migration guide: https://docs.python.org/3/howto/pyporting.html One addition I found particularly noteworthy is the "pylint --py3k" mode, which is designed to allow a project to keep their own code "Python 3 ready", even if their dependencies aren't available in Python 3 yet. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 1

Changes in Guidelines Connected to "Python 3 as Default" Change
by Bohuslav Kabrda 09 Dec '14

09 Dec '14

Hi all, as you are well aware, there is the "Python 3 as Default" change proposed for F22 [1]. There are several guideline changes that will need to be done and some that may be done in order to improve the situation. I'd like to make this thread a sort of brainstorming on my thoughts as well as possibility for anyone to add something that should be done as well. After that, I'm planning to open an FPC ticket with all the gathered and discussed changes that will come up on this thread. So here are my proposals for changes in current guidelines [2]: - In [3], it says "If the executables provide the same functionality independent of whether they are run on top of Python 2 or Python 3, then only one version of the executable should be packaged. Currently it will be the python 2 implementation, but once the Python 3 implementation is proven to work, the executable can be retired from the python 2 build and enabled in the python 3 package." - this should be changed to prefer Python 3 - (This is not really related to the switch, but more of a general remark) In [4], it says that "python 3 version of the executable gains a python3- prefix". This is IMO bad, since upstream projects tend to name the versioned binaries "foo-3.4, foo-3" or "foo3.4, foo3". We should accept one of these - I'm not really certain which one of them. I tried to discuss this several times on distutils-sig mailing list, but without reaching a consensus. Either way, prefixing with python3- doesn't make sense to me, because it's not similar to any upstream way and you don't find the binaries under their names using tab completion (e.g. foo<tab> doesn't tell you about python3-foo). - As for binaries/scripts in /usr/bin (assuming there are both python2 and python3 versions), the unversioned files should point to python2 version. This aligns with /usr/bin/python still pointing to python2. - Some time ago, I also put together a proposal for some larger changes in Python packaging [5], mostly in how the subpackages for different interpreters should be done. I opened an FPC ticket [6] to get some comments and it seemed that FPC was favorable. While I still think it'd be great to do this change, it'll require a significant effort and that is better spent helping upstreams to port to Python 3 ATM. So I'd also like to receive more comments on this proposal, although I think we should postpone it to F23 (or maybe even later). Thanks for all your comments and further suggestions. Slavek [1] http://fedoraproject.org/wiki/Changes/Python_3_as_Default [2] http://fedoraproject.org/wiki/Packaging:Python [3] http://fedoraproject.org/wiki/Packaging:Python#Guidelines [4] http://fedoraproject.org/wiki/Packaging:Python#Naming [5] https://fedoraproject.org/wiki/User:Bkabrda/Py2to3GuidelineChanges [6] https://fedorahosted.org/fpc/ticket/379

4 10

Re: [Fedora-packaging] Changes in Guidelines Connected to "Python 3 as Default" Change
by Bohuslav Kabrda 04 Dec '14

04 Dec '14

----- Original Message ----- > I hope you don't mind me chiming in on a few relevant things from Debianland. I don't mind, it's quite the opposite actually, I appreciate your comments! > On Dec 03, 2014, at 09:37 AM, Bohuslav Kabrda wrote: > > >In [3], it says "If the executables provide the same functionality > >independent of whether they are run on top of Python 2 or Python 3, then > >only > >one version of the executable should be packaged. Currently it will be the > >python 2 implementation, but once the Python 3 implementation is proven to > >work, the executable can be retired from the python 2 build and enabled in > >the python 3 package." - this should be changed to prefer Python 3 > > Debian is doing this package by package. For example, /usr/bin/tox and > /usr/bin/gtimelog are shebanged to /usr/bin/python3. Well it needs to be done case by case since some upstreams still don't support Python 3, but the point is that the guidelines should prefer and encourage usage of Python 3. > >(This is not really related to the switch, but more of a general remark) In > >[4], it says that "python 3 version of the executable gains a python3- > >prefix". This is IMO bad, since upstream projects tend to name the > >versioned binaries "foo-3.4, foo-3" or "foo3.4, foo3". We should accept one > >of these - I'm not really certain which one of them. I tried to discuss > >this several times on distutils-sig mailing list, but without reaching a > >consensus. Either way, prefixing with python3- doesn't make sense to me, > >because it's not similar to any upstream way and you don't find the > >binaries under their names using tab completion (e.g. foo<tab> doesn't tell > >you about python3-foo). > > In general, we don't provide two versions of the binaries. You won't find a > tox and tox-3 in /usr/bin. If we can provide a Python 3 version, and the > package maintainer has switched over, you'll only find the Python 3 version. > Users generally don't care what version Python their app runs on. > > There are a few exceptions, but these are limited to cases where it actually > matters which version of Python the script runs. An example of this is nose > and nose2. Because these invoke different Python executable environments, > the > shebang of these scripts does matter. E.g, we provide /usr/bin/nosetests > (#!/usr/bin/python), /usr/bin/nosetests-2.7 (#!/usr/bin/python2.7), > /usr/bin/nosetests3 (#!/usr/bin/python3). (Looks like we're missing one for > 3.4, oh well.) The same goes for apps in Fedora. Assuming that Python 2 and Python 3 versions of the binary provide the same functionality, there is only one variant. E.g. nosetests binary is packaged for both Pythons, while pygmentize just generates some output, so it doesn't need to be shipped in both 2 and 3 variants. > In these cases, the naming convention can get tricky. Usually, as you > suggest, the unversioned script is the Python 2 version, specifically > #!/usr/bin/python (or less commonly #!/usr/bin/python2 for PEP 394 > aficionados). foo-2.7 will be #!/usr/bin/python2.7 (we don't support > anything > older than that). foo-3 will be #!/usr/bin/python3 and foo-3.4 will be > #!/usr/bin/python3.4. As you can see for nosetests-under-Python-3, we're not > always consistent. > > Of course it gets a little trickier for things like nose2. nose2-3 is > #!/usr/bin/python3. Also, as mentioned in one of my previous mails, I think we should promote the naming variant with dash, since otherwise it would end up being nose23/nose23.4... > >While I still think it'd be great to do this change, it'll require a > >significant effort and that is better spent helping upstreams to port to > >Python 3 ATM. > > +1! Getting more upstreams on Python 3 helps all Pythonistas. Debian 8 > (Jessie) is in release freeze now but after that is released I will be doing > more work (along with others in our community) toward moving to a > predominantly Python 3 world. We have a couple of Debian-only packages which > are blocking a switch to Python3-installed-by-default and I'll be tackling > those first (similarly in Ubuntu). The next step is making sure that for > those upstreams that do support Python 3, that is available by default in the > archive. Then I think it's a matter of trying to switch any other scripts > which *can* run under Python 3, to do so. For our progress, see https://fedoraproject.org/wiki/User:Churchyard/python3. We've ported a good portion of these upstreams and I'm sure some of them are common with Debian. Most are ready and the rest are being worked on. > Cheers, > -Barry > Thanks for your comments. -- Regards, Slavek Kabrda

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel December 2014