Re: MBF for deprecating Python2 usage

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

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

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

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

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

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

> 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

> 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

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

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

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

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

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

> 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

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: a few quick questions on gbp pq workflow

On August 7, 2017 5:37:34 PM EDT, Diane Trout wrote: > >> >> Why would you need to repack a tarball just because it contains >> prebuilt docs (non-DFSG-free licensed documentation aside)? I'm all > >I've occasionally repacked a tarball because upstream included minified >jquery

Re: MBF for deprecating Python2 usage

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

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: a few quick questions on gbp pq workflow

> > Why would you need to repack a tarball just because it contains > prebuilt docs (non-DFSG-free licensed documentation aside)? I'm all I've occasionally repacked a tarball because upstream included minified jquery or mathjax. Diane signature.asc Description: This is a digitally signed

Re: MBF for deprecating Python2 usage

> * 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: a few quick questions on gbp pq workflow

On Aug 6, 2017, at 11:11, Ondrej Novy wrote: > It's not always possible/simple/nice to use sdist, because it contains > prebuild docs. And I don't like to do +dfsg rebuild just for removing docs. > Sometimes sdists doesn't contain tests. I will also generally prefer the PyPI

Re: Request to join DPMT

[Muri Nicanor, 2017-07-25] > i hereby request to join the debian python modules team. I want to > maintain the ansi python module [0] as part of the python modules team. > i've read and accepted both the DPMT policy [1] and the git packaging > guidelines [2]. > My username on alioth is muri-guest.

Re: a few quick questions on gbp pq workflow

On Sun, Aug 6, 2017 at 2:53 PM, Jeremy Stanley wrote: > Why would you need to repack a tarball just because it contains > prebuilt docs (non-DFSG-free licensed documentation aside)? I'd suggest removing prebuilt files should happen in both the upstream VCS and tarballs, failing that then at