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 rea
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 behaviour *already* h
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 those who need it.
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,
and I don't have th
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 –
> > ‘python
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 expect no changes to the
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 there is no better
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.
--
\ “The
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* ‘python’ command install
> 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
> 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 o
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 I am opposing is the s
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’ command will forever mean
> > Python 2.
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 Pyt
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 scripts in the wild no long
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 run the python2 c
> 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)
> > [GCC 6.4.0 20170704] on linux
>
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 /usr/bin/
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 Python 2.7.13
> T
> * 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 launching
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 th
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 ma
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 ma
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. It's clearly not t
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
> > after we remove python2.7,
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
syste
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 package. Instead
> they may
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 using it for a
> decade.
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 Python2 usage within the distributi
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
>> drop Python2 for the
[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 be
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 not be
>possible to
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 too many issues wi
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 f
37 matches
Mail list logo
