Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #8297 > unrolled thread

Use Python3 where possible

Back to article view | Back to linux.debian.maint.python

Contents

  Use Python3 where possible Matthias Klose <doko@debian.org> - 2016-03-15 11:30 +0100
    Re: Use Python3 where possible Andrey Rahmatullin <wrar@debian.org> - 2016-03-15 12:30 +0100
    Re: Use Python3 where possible Barry Warsaw <barry@debian.org> - 2016-03-15 23:30 +0100
    Re: Use Python3 where possible Thomas Goirand <zigo@debian.org> - 2016-03-16 00:40 +0100

#8297 — Use Python3 where possible

The recent update of pep8 to use Python3 by default, and the regressions 
mentioned in #807409 reminded me, that we probably should address the use of 
Python3 more pro-actively.

The pep8 binary package included the Python2 modules, plus the scripts, the 
python3-pep8 package only included the Python3 modules.  The recent upload added 
a python-pep8 package, and let the pep8 package depend on python3-pep8, breaking 
packages which use the module, but not the binary package.  I still think this 
way forward is the correct way to go (maybe adding some Breaks if these are 
known in advance).

There are probably more packages like these, which should be converted this way. 
  Maybe a popular candidate is sphinx, where almost always python-sphinx is used 
as a b-d instead of python3-sphinx.

I would like to come up with a recommendation that if a python module ships 
scripts, Python3 is used for these scripts, and the Python2 version of these 
scripts should be dropped (and python -m ...) should be used instead.  An 
alternative might be to use separate names for the scripts (e.g. ending with 2, 
or like in pillow one set without a suffix (for Python3), and one set with a .py 
suffix (Python2)).  The most conforming name for the scripts should always use 
Python3.

Having a lintian warning that a package still uses Python2 instead of Python3 
might help as well, however maybe it should start as an "information" instead of 
a warning.

Matthias

[toc] | [next] | [standalone]

#8298

On Tue, Mar 15, 2016 at 11:20:12AM +0100, Matthias Klose wrote:
> I would like to come up with a recommendation that if a python module ships
> scripts, Python3 is used for these scripts, and the Python2 version of these
> scripts should be dropped (and python -m ...) should be used instead.  An
> alternative might be to use separate names for the scripts (e.g. ending with
> 2, or like in pillow one set without a suffix (for Python3), and one set
> with a .py suffix (Python2)).  The most conforming name for the scripts
> should always use Python3.
NB: https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#8302

Probably no surprise, but I agree with everything Matthias said.

On Mar 15, 2016, at 11:20 AM, Matthias Klose wrote:

>I would like to come up with a recommendation that if a python module ships
>scripts, Python3 is used for these scripts, and the Python2 version of these
>scripts should be dropped (and python -m ...) should be used instead.  An
>alternative might be to use separate names for the scripts (e.g. ending with
>2, or like in pillow one set without a suffix (for Python3), and one set with
>a .py suffix (Python2)).  The most conforming name for the scripts should
>always use Python3.

I *really* dislike the -3 suffix on some scripts, e.g. the especially
egregious nosetests2-3.  I wouldn't want to adopt a -2 suffix, so ultimately I
agree that the /usr/bin/foo should be shebanged with python3 and drop back to
`python -m foo` for anyone who needs Python 2.

If there are cases where that won't work, let's try to fix them, or deal with
them on a case-by-case basis.

>Having a lintian warning that a package still uses Python2 instead of Python3
>might help as well, however maybe it should start as an "information" instead
>of a warning.

+1

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8303

Hi Matthias,

Thanks for bringing this topic.

On 03/15/2016 11:20 AM, Matthias Klose wrote:
> The recent update of pep8 to use Python3 by default, and the regressions
> mentioned in #807409 reminded me, that we probably should address the
> use of Python3 more pro-actively.
> 
> The pep8 binary package included the Python2 modules, plus the scripts,
> the python3-pep8 package only included the Python3 modules.  The recent
> upload added a python-pep8 package, and let the pep8 package depend on
> python3-pep8, breaking packages which use the module, but not the binary
> package.  I still think this way forward is the correct way to go (maybe
> adding some Breaks if these are known in advance).
> 
> There are probably more packages like these, which should be converted
> this way.  Maybe a popular candidate is sphinx, where almost always
> python-sphinx is used as a b-d instead of python3-sphinx.

Probably that's because it "only" generates static docs, and we don't
really care enough how they are generated. If sphinx-build was to become
Python 3 only through deprecation, then maybe we'd start migrating more
aggressively.

> I would like to come up with a recommendation that if a python module
> ships scripts, Python3 is used for these scripts, and the Python2
> version of these scripts should be dropped (and python -m ...) should be
> used instead. An alternative might be to use separate names for the
> scripts (e.g. ending with 2, or like in pillow one set without a suffix
> (for Python3), and one set with a .py suffix (Python2)).  The most
> conforming name for the scripts should always use Python3.
> 
> Having a lintian warning that a package still uses Python2 instead of
> Python3 might help as well, however maybe it should start as an
> "information" instead of a warning.
> 
> Matthias

What I'm fearing here is repeating the same mistake done with 2to3: that
we want a one time migration, instead of a smooth transition where both
are co-existing. Maybe a longer co-existance will make it less painful.

That's more the path which I'm trying to take, until all can be
definitively switched at once to Python 3: this will be the point where
I'll start removing Python 2 support, but unfortunately I don't think
we're there just yet. I'm doing as much as I can to get there though.

What I've been doing everywhere, is providing /usr/bin/python2-foo and
/usr/bin/python3-foo, then using update-alternatives to provide
/usr/bin/foo. So far, I'm setting priorities to the Python 2
implementation, until most of OpenStack is ready for Python 3 (which I
believe could happen next year, as the functional testing will start
using Python 3).

I wrote a script within openstack-pkg-tools (BTW, it should be renamed,
as this helper package is generic and not really specific to OpenStack)
to write this fast: pkgos-alternative-bin, which you use this way:

pkgos-alternative-bin foo x y z

when foo is the name of the binary package (as in: python-foo), and x y
and z are the names of the programs in /usr/bin. pkgos-alternative-bin
creates the .postinst, .postrm and .prerm for you (take care, it may
ovewrite the one you already have), and propose the mv commands to add
in debian/rules.

This proves to be *very* efficient to work with: it takes less than a
minute to implement the update-alternatives stuff in a package if you're
using pkgos-alternative-bin to automate the process.

Now, probably I should implement a new parameter to select if one wants
Python 2 or Python 3 as the default implementation, to set
update-alternatives priorities accordingly. A (trivial) contribution for
doing this would welcome.

I hope this helps, comments welcome,
Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web