Re: MBF for deprecating Python2 usage

2017-08-10 Thread Geoffrey Thomas
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

Re: MBF for deprecating Python2 usage

2017-08-08 Thread Scott Kitterman
On Tuesday, August 08, 2017 08:58:04 PM Ole Streicher wrote: > Diane Trout 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

Re: MBF for deprecating Python2 usage

2017-08-08 Thread Ole Streicher
Diane Trout 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

Re: MBF for deprecating Python2 usage

2017-08-08 Thread Ben Finney
Steve Langasek 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,

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Steve Langasek
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 – > >

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Barry Warsaw
On Aug 7, 2017, at 20:52, Ben Finney 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

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Ben Finney
Diane Trout 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

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Diane Trout
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

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Ben Finney
Diane Trout 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. -- \

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Ben Finney
Diane Trout writes: > Personally, I'm ready for python to point to python3 now. I appreciate that. In many of my hours I even concur. Both of us can have that, for our own personal environment. That doesn't answer the question of changing the behaviour of the *default*

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Diane Trout
> 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

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Diane Trout
> What tearing need is there to change what the command ‘python’ does, > in > a backward-incompatible way? Personally, I'm ready for python to point to python3 now. I'm tired of writing python 2/3 compatible code because someone _might_ launch a script with "python my_python3_script.py instead

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Ben Finney
Geoffrey Thomas 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

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Ben Finney
Barry Warsaw writes: > On Aug 7, 2017, at 18:28, Ben Finney wrote: > > > That day [when we know that the vast majority of scripts in the wild > > no longer expect Python 2 when invoking the ‘python’ command] might > > never come, in which case the ‘python’

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Geoffrey Thomas
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

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Barry Warsaw
On Aug 7, 2017, at 18:28, 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

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Ben Finney
Diane Trout writes: > My suggestion was "the startup banner should print what command to run > to get Python 2." Thanks for the suggestion. I think it's a bad idea. > I was thinking of the case of the end-user trying to follow a Python > tutorial. They'd still need to exit and

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Diane Trout
> I disagree, it's a bad idea to actively take steps to make the same > command invoke *incompatible* programs depending on the time and > host. My suggestion was "the startup banner should print what command to run to get Python 2." I was thinking of the case of the end-user trying to follow a

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Ben Finney
Barry Warsaw writes: > On Aug 7, 2017, at 14:52, Diane Trout wrote: > > Perhaps when launching via the command "python" the interpreter could > > hint python2 was available? Something like: > > > > $ python > > Python 3.5.4rc1 (default, Jul 25 2017, 08:53:34)

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Geoffrey Thomas
On Fri, 4 Aug 2017, Scott Kitterman wrote: If the primary concern is what happens when a user types "python", then can we address that in command-not-found and leave /usr/bin/python out of it? Debian doesn't ship command-not-found by default. One other approach here would be to have

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Barry Warsaw
On Aug 7, 2017, at 14:52, Diane Trout wrote: > Perhaps when launching via the command "python" the interpreter could > hint python2 was available? Something like: > > $ python > Python 3.5.4rc1 (default, Jul 25 2017, 08:53:34) > [GCC 6.4.0 20170704] on linux > Type "python2" for

Re: MBF for deprecating Python2 usage

2017-08-07 Thread Diane Trout
> * Plan for a date at which /usr/bin/python will point to Python 3.  I > know that’s the most controversial bit, but I do think that as time > goes on and we’re past 2020, it will be the choice that gives our > users the best experience. I agree the default should change. Perhaps when

Re: MBF for deprecating Python2 usage

2017-08-06 Thread Christian Seiler
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

Re: MBF for deprecating Python2 usage

2017-08-06 Thread Adrian Bunk
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

Re: MBF for deprecating Python2 usage

2017-08-04 Thread Scott Kitterman
On August 4, 2017 9:37:18 PM EDT, Barry Warsaw wrote: >Scott Kitterman wrote: > >> If the primary concern is what happens when a user types "python", >then can we >> address that in command-not-found and leave /usr/bin/python out of >it? > >I'm definitely willing to for now.

Re: MBF for deprecating Python2 usage

2017-08-04 Thread Barry Warsaw
Scott Kitterman wrote: > If the primary concern is what happens when a user types "python", then can > we > address that in command-not-found and leave /usr/bin/python out of it? I'm definitely willing to for now. It's clearly not time to remove the link or point it elsewhere anyway. I think

Re: MBF for deprecating Python2 usage

2017-08-04 Thread Scott Kitterman
On Friday, August 04, 2017 10:13:00 AM ba...@debian.org wrote: > On Aug 3, 2017, at 23:23, Scott Kitterman wrote: > > Read it. I remain completely convinced that /usr/bin/python pointing at a > > python3 version is utterly wrong and a disservice to our users. Even > >

Re: MBF for deprecating Python2 usage

2017-08-04 Thread Barry Warsaw
Ole Streicher wrote: > It is very usual to use "#!/usr/bin/env python" as shebang, exactly for > the case that python is not installed in /usr/bin. Sure, but then all bets are off. The script so shebanged can't assume anything about $PATH so it gets whatever it gets. Using /usr/bin/env in

Re: MBF for deprecating Python2 usage

2017-08-04 Thread Ole Streicher
ba...@debian.org writes: > On Aug 3, 2017, at 23:23, Scott Kitterman wrote: > You’re right that folks will still need Python 2 after 2020, and that > their best option may be to build it themselves, but I don’t think > they’ll be building and installing some old Debian

Re: MBF for deprecating Python2 usage

2017-08-04 Thread barry
On Aug 3, 2017, at 23:23, Scott Kitterman wrote: > > Read it. I remain completely convinced that /usr/bin/python pointing at a > python3 version is utterly wrong and a disservice to our users. Even after > we remove python2.7, people will be locally compiling it and

Re: MBF for deprecating Python2 usage

2017-08-04 Thread Scott Kitterman
On August 4, 2017 6:49:23 AM EDT, Matthias Klose wrote: >On 03.08.2017 21:08, ba...@debian.org wrote: >> On Aug 3, 2017, at 17:57, Matthias Klose wrote: >>> >>> While at DebCamp, Stefano Rivera and I sat down to analyze what >needs to be done >>> to deprecate

Re: MBF for deprecating Python2 usage

2017-08-04 Thread Matthias Klose
On 03.08.2017 21:08, ba...@debian.org wrote: > On Aug 3, 2017, at 17:57, 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 >>

Re: MBF for deprecating Python2 usage

2017-08-04 Thread Piotr Ożarowski
[Scott Kitterman, 2017-08-04] > Read it. I remain completely convinced that /usr/bin/python pointing > at a python3 version is utterly wrong and a disservice to our users. > Even after we remove python2.7, people will be locally compiling it > and using it for a decade. > > Such a change would

Re: MBF for deprecating Python2 usage

2017-08-03 Thread Scott Kitterman
Dropped d-devel. On August 3, 2017 9:08:10 PM EDT, ba...@debian.org wrote: >On Aug 3, 2017, at 17:57, 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

Re: MBF for deprecating Python2 usage

2017-08-03 Thread barry
On Aug 3, 2017, at 17:57, 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