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
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
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
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,
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 –
> >
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
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
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
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.
--
\
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*
> 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
> 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
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
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’
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
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
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
> 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
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)
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
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
> * 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
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
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
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.
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
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
> >
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
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
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
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
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
>>
[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
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
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
35 matches
Mail list logo