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

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

MBF for deprecating Python2 usage

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

Contents

  MBF for deprecating Python2 usage Matthias Klose <doko@debian.org> - 2017-08-04 00:00 +0200
    Re: MBF for deprecating Python2 usage barry@debian.org - 2017-08-04 03:10 +0200
      Re: MBF for deprecating Python2 usage Scott Kitterman <debian@kitterman.com> - 2017-08-04 05:30 +0200
        Re: MBF for deprecating Python2 usage Piotr Ożarowski <piotr@debian.org> - 2017-08-04 08:10 +0200
        Re: MBF for deprecating Python2 usage barry@debian.org - 2017-08-04 16:20 +0200
          Re: MBF for deprecating Python2 usage Ole Streicher <olebole@debian.org> - 2017-08-04 17:10 +0200
            Re: MBF for deprecating Python2 usage Barry Warsaw <barry@debian.org> - 2017-08-04 17:50 +0200
          Re: MBF for deprecating Python2 usage Scott Kitterman <debian@kitterman.com> - 2017-08-04 23:10 +0200
            Re: MBF for deprecating Python2 usage Barry Warsaw <barry@debian.org> - 2017-08-05 03:40 +0200
              Re: MBF for deprecating Python2 usage Scott Kitterman <debian@kitterman.com> - 2017-08-05 04:10 +0200
            Re: MBF for deprecating Python2 usage Geoffrey Thomas <geofft@ldpreload.com> - 2017-08-08 00:50 +0200
          Re: MBF for deprecating Python2 usage Diane Trout <diane@ghic.org> - 2017-08-08 00:00 +0200
            Re: MBF for deprecating Python2 usage Barry Warsaw <barry@debian.org> - 2017-08-08 00:50 +0200
              Re: MBF for deprecating Python2 usage Ben Finney <bignose@debian.org> - 2017-08-08 01:40 +0200
                Re: MBF for deprecating Python2 usage Diane Trout <diane@ghic.org> - 2017-08-08 01:50 +0200
                  Re: MBF for deprecating Python2 usage Ben Finney <bignose@debian.org> - 2017-08-08 03:40 +0200
                    Re: MBF for deprecating Python2 usage Barry Warsaw <barry@debian.org> - 2017-08-08 04:00 +0200
                      Re: MBF for deprecating Python2 usage Ben Finney <bignose@debian.org> - 2017-08-08 04:20 +0200
                        Re: MBF for deprecating Python2 usage Diane Trout <diane@ghic.org> - 2017-08-08 05:10 +0200
                          Re: MBF for deprecating Python2 usage Ben Finney <bignose@debian.org> - 2017-08-08 05:30 +0200
                            Re: MBF for deprecating Python2 usage Diane Trout <diane@ghic.org> - 2017-08-08 05:40 +0200
                              Re: MBF for deprecating Python2 usage Ben Finney <bignose@debian.org> - 2017-08-08 06:00 +0200
                                Re: MBF for deprecating Python2 usage Barry Warsaw <barry@debian.org> - 2017-08-08 07:00 +0200
                    Re: MBF for deprecating Python2 usage Geoffrey Thomas <geofft@ldpreload.com> - 2017-08-08 04:10 +0200
                      Re: MBF for deprecating Python2 usage Ben Finney <bignose@debian.org> - 2017-08-08 04:30 +0200
                        Re: MBF for deprecating Python2 usage Diane Trout <diane@ghic.org> - 2017-08-08 05:20 +0200
                          Re: MBF for deprecating Python2 usage Ben Finney <bignose@debian.org> - 2017-08-08 05:40 +0200
                          Re: MBF for deprecating Python2 usage Steve Langasek <vorlon@debian.org> - 2017-08-08 07:30 +0200
                            Re: MBF for deprecating Python2 usage Ben Finney <bignose@debian.org> - 2017-08-08 08:20 +0200
                            Re: MBF for deprecating Python2 usage Geoffrey Thomas <geofft@ldpreload.com> - 2017-08-10 17:40 +0200
                          Re: MBF for deprecating Python2 usage Ole Streicher <olebole@debian.org> - 2017-08-08 21:20 +0200
                            Re: MBF for deprecating Python2 usage Scott Kitterman <debian@kitterman.com> - 2017-08-08 21:30 +0200
      Re: MBF for deprecating Python2 usage Matthias Klose <doko@debian.org> - 2017-08-04 13:00 +0200
        Re: MBF for deprecating Python2 usage Scott Kitterman <debian@kitterman.com> - 2017-08-04 14:40 +0200
    Re: MBF for deprecating Python2 usage Adrian Bunk <bunk@debian.org> - 2017-08-07 00:00 +0200
    Re: MBF for deprecating Python2 usage Adrian Bunk <bunk@debian.org> - 2017-08-07 01:00 +0200
    Re: MBF for deprecating Python2 usage Christian Seiler <christian@iwakd.de> - 2017-08-07 01:10 +0200

Page 2 of 2 — ← Prev page 1 [2]

#9739

On Tue, 2017-08-08 at 13:24 +1000, Ben Finney wrote:
> 
> Those people, not party ot this conversation, have reasonable
> expectation that such breakage will not happen without very good
> reason.
> Good reason would entail, as an example, that there is no better
> alternative.
> 

Why not ask?

I know people in training groups like software carpentry? Does anyone
know sites with large python deployments?

I'd love to know what Apple is going to do about this issue.

Also if we do come up with a migration it should happen at a release
and be clearly reported in the release notes.

Diane

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

#9740

Diane Trout <diane@ghic.org> writes:

> On Tue, 2017-08-08 at 13:24 +1000, Ben Finney wrote:
> > 
> > Those people, not party [to] this conversation, have reasonable
> > expectation that such breakage will not happen without very good
> > reason.
> > Good reason would entail, as an example, that there is no better
> > alternative.
>
> Why not ask?

Ask whom? Because the issue is about the expectations of those who
*don't want* to be bothered by technical discussions like this, asking
those few who make themselves available for such questions will not
resolve the issue.

At best, we would have a collection of anecdotes and no idea how
representative they are of those who choose not to be contactable (but
still expect Debian to avoid breaking things unnecessarily).

At worst, we would have a collection of anecdotes that would be a strong
temptation for *falsely assuming* they represent the silent majority.

Barry, earlier in this thread, was correct when he pointed out that, by
the nature of the issue, we *can't* know with confidence what the
majority of people expect about this change.

So IMO the conservative assumption is that they expect Debian to provide
the stability it is famous for, and not to break the behaviour of
commands unnecessarily.

-- 
 \       “Some people have a problem, and they think “I know, I'll use |
  `\     Perl!”. Now they have some number of problems but they're not |
_o__)     sure whether it's a string or an integer.” —Benno Rice, 2011 |
Ben Finney

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

#9741

[Multipart message — attachments visible in raw view] — view raw

On Aug 7, 2017, at 20:52, Ben Finney <bignose@debian.org> wrote:
> 
> So IMO the conservative assumption is that they expect Debian to provide
> the stability it is famous for, and not to break the behaviour of
> commands unnecessarily.

There’s another dimension to that too: it’s people who expect no changes to the command called /usr/bin/python *and* want to track the latest and greatest Debian releases.  Maybe that changes the equation and maybe not.  Certainly any large organization with tons of Python 2 laying around is going to be much more conservative about upgrading their entire distro than individual developers who just use unstable and get whatever today’s snapshot looks like.

And to reiterate, I’m not arguing that /usr/bin/python change today or even at the end of Pycon 2020 when 2.7 is officially EOL’d.  I’m saying that it *will* change some day and that we should plan that change, if for no other reason than to set the expectations of exactly those folks who are not part of this conversation.

Cheers,
-Barry

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

#9732

[Multipart message — attachments visible in raw view] — view raw

On Tue, 8 Aug 2017, Ben Finney wrote:

> The issue is: Invoking ‘python’ today gets an interpereter, Python 2,
> that will work with some code and not others. It should not tomorrow
> invoke an incompatible interpreter without *knowing* that the vast
> majority of scripts in the wild no longer expect Python 2 to come from
> that command.
>
> That day might never come, in which case the ‘python’ command will
> forever mean Python 2. That is, I'm saying, better than breaking that
> command in the near or medium future.
>
> I'm saying it's a bad idea for ‘python’ tomorrow to get an incompatible
> intepreter that won't run the same Python code. That interpreter is
> named ‘python3’ and should never be installed as ‘python’, because
> ‘python’ is a command that many scripts expect to invoke Python 2.

This conflates the role of the interactive Python interpreter (which is 
what Diane was referring to) and a script interpreter. #!/usr/bin/python 
and `python -c` are ABI referring to Python 2, yes, and can't start 
running Python 3 any more than /lib/libc.so.5 can start being glibc. But 
there's no reason this should prevent typing "python" from giving you a 
Python 3 interpreter.

Since I think it hasn't been linked recently on this list, I'll re-link 
this project, which separates the two roles:

     https://github.com/geofft/pythonmux
     https://ldpreload.com/blog/usr-bin-python-23

Keep in mind that we do intend to break the ability for /usr/bin/python to 
run Python 2 code in less than three years (unless we're interested in 
providing security support for Python 2 when it's dead upstream, which I 
hope nobody wants to do). We will not indefinitely provide a 
/usr/bin/python that runs Python 2; we probably will do so for at most one 
more stable release.

The only question is whether it should break by giving you an error 
message (either ENOENT or something printed on stderr), or break by trying 
to run the code as Python 3.

-- 
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com

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

#9734

Geoffrey Thomas <geofft@ldpreload.com> writes:

> We will not indefinitely provide a /usr/bin/python that runs Python 2;
> we probably will do so for at most one more stable release.

I'm fine with removing the ‘python’ command, because that command means
Python 2 and Python 2 is going away.

What I am opposing is the suggestion to install, in the near to medium
term, a command of exactly the same name that has subtly similar but
incompatible behaviour, when that behaviour *already* has a command –
‘python3’ – that is widely used by those who need it.

-- 
 \       “From the moment I picked your book up until I laid it down I |
  `\        was convulsed with laughter. Someday I intend reading it.” |
_o__)                                                    —Groucho Marx |
Ben Finney

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

#9736

> What I am opposing is the suggestion to install, in the near to
> medium
> term, a command of exactly the same name that has subtly similar but
> incompatible behaviour, when that behaviour *already* has a command –
> ‘python3’ – that is widely used by those who need it.
> 

my problem with that plan is all of the printed documentation saying to
learn python, type "python".

At the very least there needs to a usr/bin/python that prints
instructions about what you should run.

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

#9738

Diane Trout <diane@ghic.org> writes:

> my problem with that plan is all of the printed documentation saying
> to learn python, type "python".

I agree that's a problem.

I don't agree that making a backward incompatible breakage is justified
by widespread documentation giving bad advice.

-- 
 \              “There are no chaplains in foxholes.” —Sergeant Justin |
  `\                                              Griffith, 2011-07-27 |
_o__)                                                                  |
Ben Finney

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

#9742

[Multipart message — attachments visible in raw view] — view raw

On Mon, Aug 07, 2017 at 08:11:40PM -0700, Diane Trout wrote:

> > What I am opposing is the suggestion to install, in the near to
> > medium
> > term, a command of exactly the same name that has subtly similar but
> > incompatible behaviour, when that behaviour *already* has a command –
> > ‘python3’ – that is widely used by those who need it.

> my problem with that plan is all of the printed documentation saying to
> learn python, type "python".

> At the very least there needs to a usr/bin/python that prints
> instructions about what you should run.

FWIW I don't share Ben's concern about this being a "backwards incompatible"
change (who is relying on the precise contents of the banner when running
'python' interactively?!).

But I am concerned about possible implementation strategies here.  exec() is
a very expensive syscall, and python is a frequently used interpreter.  If
this were implemented as a wrapper that checked isatty(), printed a banner,
and then re-execed the real python, that could have a measurable performance
impact on some applications.  There is a reason /usr/bin/python,
/usr/bin/gcc, etc. are always symlinks to the real interpreter on Debian,
not wrapper scripts - other distributions have tried to do this as a wrapper
script and the result wasn't pretty.

Avoiding the performance hit would require that any changes to the banner
be made in the python source itself.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

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

#9743

Steve Langasek <vorlon@debian.org> writes:

> FWIW I don't share Ben's concern about this being a "backwards
> incompatible" change (who is relying on the precise contents of the
> banner when running 'python' interactively?!).

That's not a backward incompatibility anyone would seriously rely on,
and I don't have that concern.

The backward incompatibility I'm concerned about is: to have ‘python’,
which today invokes Python 2 and some uncountable number of scripts rely
on, change on a near-to-medium future upgrade to instead invoke the
backward-incompatible Python 3 hence breaking those scripts.

Merely noting a change in the interactive prompt's banner is, I agree,
inconsequential by comparison. So that's not the objection.

-- 
 \        “All opinions are not equal. Some are a very great deal more |
  `\   robust, sophisticated, and well supported in logic and argument |
_o__)                                     than others.” —Douglas Adams |
Ben Finney

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

#9746

On Mon, 7 Aug 2017, Steve Langasek wrote:

> But I am concerned about possible implementation strategies here.  exec() is
> a very expensive syscall, and python is a frequently used interpreter.  If
> this were implemented as a wrapper that checked isatty(), printed a banner,
> and then re-execed the real python, that could have a measurable performance
> impact on some applications.  There is a reason /usr/bin/python,
> /usr/bin/gcc, etc. are always symlinks to the real interpreter on Debian,
> not wrapper scripts - other distributions have tried to do this as a wrapper
> script and the result wasn't pretty.

Python itself is not very fast to start up, though, so exec is not the 
dominating cost. Some ad-hoc testing with the current version of pythonmux 
(which uses the re-exec approach) shows that it takes about 13.8 ms to 
print("Hello world") with /usr/bin/python and 15.5 ms to print("Hello 
world") with pythonmux on my 2010-ish laptop.

For the sake of argument, I just pushed a branch of pythonmux that links 
libpython3.5 and calls Py_Main instead of execing python3.5 (that is, if 
the target interpreter is python3.5, it will not actually exec):

   https://github.com/geofft/pythonmux/commits/libpython

But it's quite a bit _slower_ with this approach (about 26.9 ms per run), 
regardless of whether I link libpython3.5m.so or libpython3.5m.a. This 
confuses me and I'm definitely curious to figure this out if that's worth 
doing, but I think this is getting into a lot of weird complexity to save 
1.7 ms on a mere hello world -- for comparison, if I add `import requests` 
to my hello world program, each run now takes about 342 ms.

By the way, I do think I made pythonmux do too much since I wanted to make 
it useful in the general case; in particular I don't think it's super 
helpful to support scripts that say "I can run on Python 3.2 but not any 
newer version". Given the way the discussion is going (both here and on 
linux-sig) and how close we are to Python 2's end-of-life, I think it's 
sufficient to check isatty(0) and the shebang line if one exists, call 
libpython3's Py_Main if that seems reasonable, print a warning and attempt 
to exec python2 otherwise, and print an error message about how to install 
python2 if the exec fails.

-- 
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com

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

#9744

Diane Trout <diane@ghic.org> writes:
>> What I am opposing is the suggestion to install, in the near to
>> medium
>> term, a command of exactly the same name that has subtly similar but
>> incompatible behaviour, when that behaviour *already* has a command –
>> ‘python3’ – that is widely used by those who need it.
>> 
>
> my problem with that plan is all of the printed documentation saying to
> learn python, type "python".

All *actual* printed documentation? Which refers to Python 3? Could you
give an example here?

Otherwise, (if using a Python 2 book), one of the next steps would be
"print 'hello world'", and nothing would prevent from the horrible
experience that the book is outdated anyway.

Sorry, I don't see the problem with "printed documentation".

Best regards

Ole

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

#9745

On Tuesday, August 08, 2017 08:58:04 PM Ole Streicher wrote:
> Diane Trout <diane@ghic.org> writes:
> >> What I am opposing is the suggestion to install, in the near to
> >> medium
> >> term, a command of exactly the same name that has subtly similar but
> >> incompatible behaviour, when that behaviour *already* has a command –
> >> ‘python3’ – that is widely used by those who need it.
> > 
> > my problem with that plan is all of the printed documentation saying to
> > learn python, type "python".
> 
> All *actual* printed documentation? Which refers to Python 3? Could you
> give an example here?
> 
> Otherwise, (if using a Python 2 book), one of the next steps would be
> "print 'hello world'", and nothing would prevent from the horrible
> experience that the book is outdated anyway.
> 
> Sorry, I don't see the problem with "printed documentation".

Having recently (late last year) searched for a beginner's Python book for one 
of my kids, I can tell you that current offers range between "Only a few 
people use Python 3, so you're better off ignoring this odd duck while you 
learn" to "Python 3 is the future, so you may as well start be learning the 
future rather than the past".  I don't recall any current books that didn't at 
least acknowledge the existence of this Python 3 thing.

Based on that (admittedly incomplete) survey, I think confusion about the 
existence of Python/Python 3 is a problem with current dead tree learning 
Python editions.  If you're trying to learn something new with old 
documentation, I don't think it should be surprising there are a few bumps 
along the way.

I agree.

Scott K

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

#9692

On 03.08.2017 21:08, barry@debian.org wrote:
> On Aug 3, 2017, at 17:57, Matthias Klose <doko@debian.org> wrote:
>>
>> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be done
>> to deprecate Python2 usage within the distribution.  It might not be possible to
>> drop Python2 for the next release, but there are still too many issues with
>> packages.  For now we identified some categories which need fixing. These are
>> documented at https://wiki.debian.org/Sprints/2017/Python3Montreal, resulting in
>> more than 3000 bug reports.  That's a high number, on the other hand we won't
>> make much progress if the issues are not named.  My intent is to bring that up
>> in the Python BoF next week at DebConf and then filing these bug reports with
>> the user tags mentiond on the wiki page.
> 
> Great to hear that you guys talked about it.
> 
> Just a quick note that PEP 394 discussions have revived, lead by the Fedora folks.  Please do check out the new thread, especially if you have opinions about what /usr/bin/python should do once Python 2.7 is EOL.
> 
> https://mail.python.org/pipermail/linux-sig/2017-August/thread.html

I replied to this thread.  I think there should be one release which is not
shipping /usr/bin/python before /usr/bin/python should be reused and pointed at
python (>> 2). This should be good enough to get all scripts actively converted
which are not part of the distribution.  If that release is buster, we should
require the use of python2 instead of python now, document that in policy and
provide a lintian check for that.

Matthias

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

#9693

On August 4, 2017 6:49:23 AM EDT, Matthias Klose <doko@debian.org> wrote:
>On 03.08.2017 21:08, barry@debian.org wrote:
>> On Aug 3, 2017, at 17:57, Matthias Klose <doko@debian.org> wrote:
>>>
>>> While at DebCamp, Stefano Rivera and I sat down to analyze what
>needs to be done
>>> to deprecate Python2 usage within the distribution.  It might not be
>possible to
>>> drop Python2 for the next release, but there are still too many
>issues with
>>> packages.  For now we identified some categories which need fixing.
>These are
>>> documented at https://wiki.debian.org/Sprints/2017/Python3Montreal,
>resulting in
>>> more than 3000 bug reports.  That's a high number, on the other hand
>we won't
>>> make much progress if the issues are not named.  My intent is to
>bring that up
>>> in the Python BoF next week at DebConf and then filing these bug
>reports with
>>> the user tags mentiond on the wiki page.
>> 
>> Great to hear that you guys talked about it.
>> 
>> Just a quick note that PEP 394 discussions have revived, lead by the
>Fedora folks.  Please do check out the new thread, especially if you
>have opinions about what /usr/bin/python should do once Python 2.7 is
>EOL.
>> 
>> https://mail.python.org/pipermail/linux-sig/2017-August/thread.html
>
>I replied to this thread.  I think there should be one release which is
>not
>shipping /usr/bin/python before /usr/bin/python should be reused and
>pointed at
>python (>> 2). This should be good enough to get all scripts actively
>converted
>which are not part of the distribution.  If that release is buster, we
>should
>require the use of python2 instead of python now, document that in
>policy and
>provide a lintian check for that.
>
>Matthias

I disagree.

There will be users whose reaction to removal of python2.7 will be to compile their own.

Reintroducing /usr/bin/python as a python3 version risks their systems for no benefit (since all python3 stuff points to /usr/bin/python3 and works fine).  Just let it go and don't bring it back.

As far as when to drop it goes, I believe that the python-django maintainers are planning on releasing Buster with Django 1.11 as bilingual python2/python3.  Then they'll go to Django 2, which is python3 only, early in the Bullseye cycle.

For the chunk of the Python ecosystem that is built around Django, keeping python2.7 in for Buster would be a significant aid to transition.

Scott K

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

#9714

On Thu, Aug 03, 2017 at 05:57:01PM -0400, Matthias Klose wrote:
> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be done
> to deprecate Python2 usage within the distribution.  It might not be possible to
> drop Python2 for the next release, but there are still too many issues with
> packages.  For now we identified some categories which need fixing. These are
> documented at https://wiki.debian.org/Sprints/2017/Python3Montreal, resulting in
> more than 3000 bug reports.  That's a high number, on the other hand we won't
> make much progress if the issues are not named.  My intent is to bring that up
> in the Python BoF next week at DebConf and then filing these bug reports with
> the user tags mentiond on the wiki page.

I do not see the benefits of the MBF.

Visibility will already be provided both to you and to package 
maintainers by lintian, with automated checking by lintian
actually more reliable than information in the BTS.

And maintainers who ignore lintian results in their packages tend to be 
the same people who ignore non-RC bugs in their packages.

> Matthias

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

#9716

On Thu, Aug 03, 2017 at 05:57:01PM -0400, Matthias Klose wrote:
> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be done
> to deprecate Python2 usage within the distribution.  It might not be possible to
> drop Python2 for the next release, but there are still too many issues with
> packages.  For now we identified some categories which need fixing. These are
> documented at https://wiki.debian.org/Sprints/2017/Python3Montreal, resulting in
> more than 3000 bug reports.  That's a high number, on the other hand we won't
> make much progress if the issues are not named.  My intent is to bring that up
> in the Python BoF next week at DebConf and then filing these bug reports with
> the user tags mentiond on the wiki page.

For python3-app I would actually consider it a bad idea to make it 
visible at this point in time (except for native packages):

I can clearly see how for example python3-package from your list is an 
issue that can become painful for users in buster, but whether a program 
uses Python2, Python3 or Perl is usually irrelevant for the user.

In 2020 when Python2 is already EOL and other distributions have already 
removed Python2, Debian will get this in most cases automatically just 
by upgrading to the latest upstream version.

Trying to do anything about python3-app already in 2017 would only 
create extra work with close to zero benefits to users of Debian.

And what should a maintainer do based on a python3-app bug or lintian warning?
"Please convert to Python3, the 2021 release of Debian will drop Python2"
sounds hilarious if sent to upstream today.

> Matthias

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

#9718

Hi Matthias,

On 08/03/2017 11:57 PM, Matthias Klose wrote:
> It might not be possible to drop Python2 for the next release,

Even if all Python-related packages in Debian were compatible with
Python3, I don't think it's a good idea to drop Python2 support in
Buster, there are still far too many third-party users of Python2
out there. I also don't think there has been enough communication
to users of Debian that Python2 is going to be removed at some
point - this has mainly been discussed in development channels so
far. And while there's writing on the wall due to upstream's EOL
of Python2 I do get the impression that many people are not aware
of that.

Therefore I would strongly recommend to keep Python2 in Buster,
but add a big fat comment to the release notes that it will be the
last Debian release that will support Python2 - so that it can be
dropped in Bullseye.

That said, I do think we should strive to get rid of all the
Python2-only packages in Buster if possible, so I do appreciate
your efforts in this regard.

Regards,
Christian

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web