On 30 April 2018 at 18:11, Victor Stinner wrote:
> 2018-04-27 17:37 GMT+02:00 Petr Viktorin :
> > (...)
> > - The paragraph about the anticipated future where python points to
> Python 3
> > is removed.
>
> Instead of editing old PEPs, would it make sense to write a new one
> which replaces the o
2018-04-27 17:37 GMT+02:00 Petr Viktorin :
> (...)
> - The paragraph about the anticipated future where python points to Python 3
> is removed.
Instead of editing old PEPs, would it make sense to write a new one
which replaces the old one?
The PEP 394 has been written in 2011 and accepted in 2012
On 28 April 2018 at 05:08, Nick Coghlan wrote:
> On 28 April 2018 at 12:34, Guido van Rossum wrote:
>>
>> Um, the PEP has "Unix-Like Systems" in its heading, so discussing the
>> Windows situation seems out of scope to me.
>
> Sorry, I conflated two issues there - while PEP 394 itself is specific
On 2018-04-28, 01:23 GMT, Nick Coghlan wrote:
> That isn't currently *my* desired future, as I don't want to
> see a python3 to python4 naming transition at any point,
> I want a transition from python3 back to an unqualified name
> to accurately reflect the change in version management
> philo
On 28 April 2018 at 12:34, Guido van Rossum wrote:
> Um, the PEP has "Unix-Like Systems" in its heading, so discussing the
> Windows situation seems out of scope to me.
>
Sorry, I conflated two issues there - while PEP 394 itself is specific to
Unix-like systems, my thoughts on where I'd like to
On Fri, Apr 27, 2018 at 7:23 PM, Nick Coghlan wrote:
> The key missing piece for doing that would be to define how we'd want a `py`
> launcher to work on *nix systems, and then provide that as part of CPython
> 3.8+ (and potentially backport it to a 3.7x maintenance release).
I was thinking along
Um, the PEP has "Unix-Like Systems" in its heading, so discussing the
Windows situation seems out of scope to me.
You're one of its authors, so if you really want to keep the paragraph
about the anticipated unified future we can keep it (though preferably this
should be discussed in the issue, htt
On 28 April 2018 at 01:37, Petr Viktorin wrote:
> Hello,
> After discussion on the [Pull Request], my update to PEP 394 changed scope
> somewhat. The new major changes are:
>
> - The `python` command may not exist at all in some cases (see the PEP for
> details)
> - The paragraph about the antici
Hello,
After discussion on the [Pull Request], my update to PEP 394 changed
scope somewhat. The new major changes are:
- The `python` command may not exist at all in some cases (see the PEP
for details)
- The paragraph about the anticipated future where python points to
Python 3 is removed. (
On 04/27/18 02:03, Ben Finney wrote:
Ben Finney writes:
Petr Viktorin writes:
[…] we feel that the only way to *enforce* that guidelines is to
provide environments where the `python` command does not work
(unless explicitly installed).
Yes. The ‘python’ command is confusing, for the rea
Ben Finney writes:
> Petr Viktorin writes:
>
> > […] we feel that the only way to *enforce* that guidelines is to
> > provide environments where the `python` command does not work
> > (unless explicitly installed).
>
> Yes. The ‘python’ command is confusing, for the reasons you say. There
> shou
Petr Viktorin writes:
> In Fedora, I found that PEP 394's strict recommendation that `python`
> points to `python2` is holding us back.
I have read the message, but I don't see how you draw the link that PEP
394 is holding you back.
> The problems are:
> - For developers that are not following
Hello,
In Fedora, I found that PEP 394's strict recommendation that `python`
points to `python2` is holding us back. From discussions on Zulip and
elsewhere it's clear that this recommendation is not changing any time
soon, but I would like to officially relax it in several cases.
The problem
- Original Message -
> On 30 September 2014 20:13, Bohuslav Kabrda wrote:
> > - Original Message -
> >> On 20 September 2014 00:23, Donald Stufft wrote:
> >> >
> >> > On Sep 19, 2014, at 10:16 AM, Barry Warsaw wrote:
> >> >
> >> > If the user wants to invoke Python 3, it's not ha
On 30 September 2014 20:13, Bohuslav Kabrda wrote:
> - Original Message -
>> On 20 September 2014 00:23, Donald Stufft wrote:
>> >
>> > On Sep 19, 2014, at 10:16 AM, Barry Warsaw wrote:
>> >
>> > If the user wants to invoke Python 3, it's not hard to type 'python3' and I
>> > think that'
- Original Message -
> On 20 September 2014 00:23, Donald Stufft wrote:
> >
> > On Sep 19, 2014, at 10:16 AM, Barry Warsaw wrote:
> >
> > If the user wants to invoke Python 3, it's not hard to type 'python3' and I
> > think that's the message we should be spreading. That already seems pr
Barry Warsaw wrote:
On Sep 19, 2014, at 08:40 AM, Guido van Rossum wrote:
Until I say so. Which will happen in the distant future.
I'm gonna hid your time machine keys so you didn't find them.
Hiding someone's time machine keys never works. Chances are
he's already taken a trip to the futur
>
> On Sep 19, 2014, at 8:02 PM, Greg Ewing wrote:
>
> Donald Stufft wrote:
>
>> My biggest problem with ``python3``, is what happens after 3.9.
>
> Python2 technically includes 1.x versions as well, so it
> wouldn't be unprecedented for python3 to imply versions
> beyond 3.x. It would be a bi
Donald Stufft wrote:
My biggest problem with ``python3``, is what happens after 3.9.
Python2 technically includes 1.x versions as well, so it
wouldn't be unprecedented for python3 to imply versions
beyond 3.x. It would be a bit confusing, though.
--
Greg
__
On 20 September 2014 00:23, Donald Stufft wrote:
>
> On Sep 19, 2014, at 10:16 AM, Barry Warsaw wrote:
>
> If the user wants to invoke Python 3, it's not hard to type 'python3' and I
> think that's the message we should be spreading. That already seems pretty
> ingrained in user habits afaict.
>
On Sep 19, 2014, at 08:40 AM, Guido van Rossum wrote:
>Until I say so. Which will happen in the distant future.
I'm gonna hid your time machine keys so you didn't find them.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.o
On Sep 19, 2014 8:36 AM, "Antoine Pitrou" wrote:
>
> On Fri, 19 Sep 2014 08:20:48 -0700
> Guido van Rossum wrote:
> > "python" should always be the same as "python2".
>
> "Always" as in "eternally"?
Until I say so. Which will happen in the distant future.
On Fri, 19 Sep 2014 08:20:48 -0700
Guido van Rossum wrote:
> "python" should always be the same as "python2".
"Always" as in "eternally"?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
Donald Stufft :
> My biggest problem with ``python3``, is what happens after 3.9. I know
> Guido doesn’t particularly like two digit version numbers and it’s
> been suggested on this list that instead of 3.10 we’re likely to move
> directly into 4.0 regardless of if it’s a “big” change or not.
py
"python" should always be the same as "python2".
On Fri, Sep 19, 2014 at 8:03 AM, Steven D'Aprano
wrote:
> On Fri, Sep 19, 2014 at 10:41:58AM -0400, Barry Warsaw wrote:
> > On Sep 19, 2014, at 10:23 AM, Donald Stufft wrote:
> >
> > >My biggest problem with ``python3``, is what happens after 3.9.
On Fri, 19 Sep 2014 10:16:20 -0400, Barry Warsaw wrote:
> The way I look at it is that "/usr/bin/python" is user interface.
> Distributions are completely free to choose whichever Python they want for
> system scripts, and it's great to see that Fedora is well on their way to
> making Python 3 the
On Fri, Sep 19, 2014 at 10:41:58AM -0400, Barry Warsaw wrote:
> On Sep 19, 2014, at 10:23 AM, Donald Stufft wrote:
>
> >My biggest problem with ``python3``, is what happens after 3.9.
>
> FWIW, 3.9 by my rough calculation is 7 years away.
That makes it 2021, one year after Python 2.7 free suppor
On Sep 19, 2014, at 10:23 AM, Donald Stufft wrote:
>My biggest problem with ``python3``, is what happens after 3.9.
FWIW, 3.9 by my rough calculation is 7 years away.
>I know Guido doesn’t particularly like two digit version numbers and it’s
>been suggested on this list that instead of 3.10 we’r
> On Sep 19, 2014, at 10:16 AM, Barry Warsaw wrote:
>
> If the user wants to invoke Python 3, it's not hard to type 'python3' and I
> think that's the message we should be spreading. That already seems pretty
> ingrained in user habits afaict.
My biggest problem with ``python3``, is what happ
On Sep 19, 2014, at 03:31 AM, Bohuslav Kabrda wrote:
>as Fedora is getting closer to having python3 as a default, I'm being more
>and more asked by Fedora users/contributors what'll "/usr/bin/python" invoke
>when we achieve this (Fedora 22 hopefully). So I was rereading PEP 394 and I
>think I need
There are many python2 only scripts with "#!/usr/bin/python" or
"#!/usr/bin/env python" shebang in the world.
I think Ubuntu and Fedora's strategy is better for now.
On Fri, Sep 19, 2014 at 7:12 PM, Bohuslav Kabrda wrote:
>
>
>
>
> On 19 Sep 2014 17:38, "Bohusla
- Original Message -
> On 19 Sep 2014 17:38, "Bohuslav Kabrda" < bkab...@redhat.com > wrote:
> > - "Similarly, the more general python command should be installed whenever
> > any version of Python is installed and should invoke the same version of
> > Python as either python2 or python3."
On 19 Sep 2014 17:38, "Bohuslav Kabrda" wrote:
> - "Similarly, the more general python command should be installed
whenever any version of Python is installed and should invoke the same
version of Python as either python2 or python3."
>
> The important word in the second point is, I think, *whenev
On Fri, Sep 19, 2014 at 04:44:26AM -0400, Donald Stufft wrote:
>
> > On Sep 19, 2014, at 3:31 AM, Bohuslav Kabrda wrote:
> >
> > Hi, as Fedora is getting closer to having python3 as a default, I'm
> > being more and more asked by Fedora users/contributors what'll
> > "/usr/bin/python" invoke w
> On Sep 19, 2014, at 3:31 AM, Bohuslav Kabrda wrote:
>
> Hi,
> as Fedora is getting closer to having python3 as a default, I'm being more
> and more asked by Fedora users/contributors what'll "/usr/bin/python" invoke
> when we achieve this (Fedora 22 hopefully). So I was rereading PEP 394 and
Hi,
as Fedora is getting closer to having python3 as a default, I'm being more and
more asked by Fedora users/contributors what'll "/usr/bin/python" invoke when
we achieve this (Fedora 22 hopefully). So I was rereading PEP 394 and I think I
need a small clarification regarding two points in the
On Tue, Feb 21, 2012 at 12:58 AM, anatoly techtonik wrote:
> On Mon, Feb 20, 2012 at 4:58 PM, Nick Coghlan wrote:
>>
>> PEP 394
>> was at the top of my list recently
>
>
> I've tried to edit it to be a little bit shorter (perhaps cleaner) and
> commented (up to revision 2) up to Migration Notes.
ArchLinux has used `python` as alias for `python3` while `python2` is
still supported.
On Mon, Feb 20, 2012 at 4:58 PM, anatoly techtonik wrote:
> On Mon, Feb 20, 2012 at 4:58 PM, Nick Coghlan wrote:
>>
>> PEP 394
>> was at the top of my list recently
>
>
> I've tried to edit it to be a little b
On Mon, Feb 20, 2012 at 4:58 PM, Nick Coghlan wrote:
> PEP 394
> was at the top of my list recently
>
I've tried to edit it to be a little bit shorter (perhaps cleaner) and
commented (up to revision 2) up to Migration Notes.
http://piratepad.net/pep-0394
The main points:
1. `python2.7` should b
Thanks Nick, Ned, and everyone else who worked on implementing this! If any
further work on the text of the PEP or on the Makefile patch is needed,
please shoot me an email (I have GMail set to archive messages to
python-dev unless they explicitly CC me).
-Kerrick Staley
On Fri, Feb 17, 2012 at 6
In article <4f3cd403.7070...@v.loewis.de>,
"Martin v. Lowis" wrote:
> > There are two issues that I know of for OS X. One is just getting a
> > python2 symlink into the bin directory of a framework build. That's
> > easy.
>
> Where exactly in the Makefile is that reflected? ISTM that the cu
On Fri, Feb 17, 2012 at 10:27 PM, Nick Coghlan wrote:
> Unfortunately, dinsdale appears to have fallen over again, so I can't
> push the change right now :(
It appears that was a temporary glitch - the 2.7 change is now in Mercurial.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
On Fri, Feb 17, 2012 at 4:57 PM, "Martin v. Löwis" wrote:
> As the PEP czar for PEP 394, I have reviewed it and am happy to say that
> I can accept it.
Excellent news, thanks!
I've pushed an updated version promoting it to Active status, and also
incorporating Barry's suggestion of making it exp
Congratulations to Kerrick Staley and Nick Coghlan, the authors of the
PEP! It's good to hear that the "python", "python2" and "python3"
symlinks are now standardized in a PEP. I hope that most Linux
distributions will follow this PEP :-)
Victor
___
Pyth
As the PEP czar for PEP 394, I have reviewed it and am happy to say that
I can accept it. I suppose that Nick will keep track of actually
implementing it in Python 2.7.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
On Feb 16, 2012, at 09:54 PM, Nick Coghlan wrote:
>It turns out I'd forgotten what was in the PEP - the Notes section
>already contained a lot of suggestions along those lines. I changed
>the title of the section to "Migration Notes", but tried to make it
>clear that those *aren't* consensus recom
I'm away from the source for the next 36 hours. I'll reply with patches by
Saturday morning.
___
Ned Deily
n...@acm.org -- []
. Original Message ...
On Thu, 16 Feb 2012 11:01:39 +0100 ""Martin v. Löwis""
wrote:
>> There are two issues that I know of for OS X. One is just gettin
On Wed, Feb 15, 2012 at 12:44 AM, Barry Warsaw wrote:
> On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote:
>>I have no idea, and I'm not going to open that can of worms for this
>>PEP. We need to say something about the executable aliases so that
>>people can eventually write cross-platform python2
On Thu, Feb 16, 2012 at 8:01 PM, "Martin v. Löwis" wrote:
> It may be that the PEP becomes irrelevant before it is widely accepted:
> if the sole remaining Python 2 version is 2.7, users may just as well
> refer to python2 as python2.7.
My hope is that a clear signal from us supporting a python2
> There are two issues that I know of for OS X. One is just getting a
> python2 symlink into the bin directory of a framework build. That's
> easy.
Where exactly in the Makefile is that reflected? ISTM that the current
patch already covers that, since the framwork* targets are not concerned
wi
In article
,
Nick Coghlan wrote:
> On Thu, Feb 16, 2012 at 12:06 PM, Guido van Rossum wrote:
> > Anyway, I don't think anyone is objecting against the PEP allowing symlinks
> > now.
>
> Yeah, the onus is just back on me to do the final updates to the PEP
> and patch based on the discussion i
On Thu, Feb 16, 2012 at 12:06 PM, Guido van Rossum wrote:
> Anyway, I don't think anyone is objecting against the PEP allowing symlinks
> now.
Yeah, the onus is just back on me to do the final updates to the PEP
and patch based on the discussion in this thread. Unless life
unexpectedly intervene
On Wed, Feb 15, 2012 at 5:26 PM, Neil Schemenauer wrote:
> Guido van Rossum wrote:
>> Does this need a pronouncement? Worrying about the speed of symlinks
>> seems silly
>
> I agree. I wonder if a hard-link was used for legacy reasons. Some
> very old versions of Unix didn't have symlinks. It
+1 for using symlinks where possible. In deploying Python to different
operating systems and filesystems I've often had to run a script to "fix"
the hardlinking done by make install because the deployment mechanism or
system couldn't be trusted to do the right thing with respect to minimising
insta
Guido van Rossum wrote:
> Does this need a pronouncement? Worrying about the speed of symlinks
> seems silly
I agree. I wonder if a hard-link was used for legacy reasons. Some
very old versions of Unix didn't have symlinks. It looks like it
was introduced in BSD 4.2, released in 1983. That se
On Feb 15, 2012, at 09:20 AM, Guido van Rossum wrote:
>Does this need a pronouncement? Worrying about the speed of symlinks
>seems silly, and exactly how the links are created (hard or soft,
>chaining or direct) should be up to the distro; our own Makefile
>should create chaining symlinks just so
Does this need a pronouncement? Worrying about the speed of symlinks
seems silly, and exactly how the links are created (hard or soft,
chaining or direct) should be up to the distro; our own Makefile
should create chaining symlinks just so the mechanism is clear.
--
--Guido van Rossum (python.org
On Wed, Feb 15, 2012 at 12:44 AM, Barry Warsaw wrote:
> On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote:
>
>>> One other thing I'd like to see the PEP address is a possible migration
>>> strategy to python->python3. Even if that strategy is "don't do it, man!".
>>> IOW, can a distribution change
On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote:
>> One other thing I'd like to see the PEP address is a possible migration
>> strategy to python->python3. Even if that strategy is "don't do it, man!".
>> IOW, can a distribution change the 'python' symlink once it's pointed to
>> python2? What
On Tue, Feb 14, 2012 at 8:08 AM, Barry Warsaw wrote:
> On Feb 13, 2012, at 12:31 PM, Nick Coghlan wrote:
>
>>I think Antoine makes a good point about ease of introspection when
>>you have multiple versions in the same series installed, so I'd be
>>fine with:
>>- updating the PEP recommendation to
On Tue, Feb 14, 2012 at 7:07 AM, "Martin v. Löwis" wrote:
>> I think Antoine makes a good point about ease of introspection when
>> you have multiple versions in the same series installed, so I'd be
>> fine with:
>> - updating the PEP recommendation to say that either form of link is
>> fine (with
On Feb 13, 2012, at 12:31 PM, Nick Coghlan wrote:
>I think Antoine makes a good point about ease of introspection when
>you have multiple versions in the same series installed, so I'd be
>fine with:
>- updating the PEP recommendation to say that either form of link is
>fine (with hard links margin
> I think Antoine makes a good point about ease of introspection when
> you have multiple versions in the same series installed, so I'd be
> fine with:
> - updating the PEP recommendation to say that either form of link is
> fine (with hard links marginally faster, but harder to introspect)
> - not
On Mon, Feb 13, 2012 at 6:42 AM, "Martin v. Löwis" wrote:
>> IMO a symlink is far and away the better choice in this situation.
>
> Please wait with that judgment until you see the rationale of the PEP
> author.
Kerrick did post a rationale in the last thread [1], but it never made
it into the PE
> IMO a symlink is far and away the better choice in this situation.
Please wait with that judgment until you see the rationale of the PEP
author.
Thanks,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
On 12Feb2012 18:57, "Martin v. Löwis" wrote:
| Am 12.02.2012 17:04, schrieb Antoine Pitrou:
| > Le dimanche 12 février 2012 à 16:52 +0100, "Martin v. Löwis" a écrit :
| >>> Why hard links? Symlinks are much more introspectable. When looking at
| >>> a hard link I have no easy way to know it's the
Am 12.02.2012 17:04, schrieb Antoine Pitrou:
> Le dimanche 12 février 2012 à 16:52 +0100, "Martin v. Löwis" a écrit :
>>> Why hard links? Symlinks are much more introspectable. When looking at
>>> a hard link I have no easy way to know it's the same as whatever other
>>> file in the same directory.
>> There actually *is* an easy way, in regular ls: look at the link count.
>> It comes out of ls -l by default, and if it's >1, there will be an
>> identical file.
>
> This doesn't tell me which file it is, which is practically useless if I
> have both python3.3 and python3.2 in that directory.
Yo
In article
,
Nick Coghlan wrote:
> PEP 394 [1] aims to document our collective recommendation for
> allowing shebang lines to specifically request some version of 2.x,
> without requiring that it be exactly 2.7 (or 2.6, etc).
>
> I'd let this drift for a while, but the imminent release of 2.7.
Le dimanche 12 février 2012 à 16:52 +0100, "Martin v. Löwis" a écrit :
> > Why hard links? Symlinks are much more introspectable. When looking at
> > a hard link I have no easy way to know it's the same as whatever other
> > file in the same directory.
>
> There actually *is* an easy way, in regul
> Why hard links? Symlinks are much more introspectable. When looking at
> a hard link I have no easy way to know it's the same as whatever other
> file in the same directory.
There actually *is* an easy way, in regular ls: look at the link count.
It comes out of ls -l by default, and if it's >1,
On Sun, 12 Feb 2012 19:04:30 +1000
Nick Coghlan wrote:
> PEP 394 [1] aims to document our collective recommendation for
> allowing shebang lines to specifically request some version of 2.x,
> without requiring that it be exactly 2.7 (or 2.6, etc).
>
> I'd let this drift for a while, but the immi
PEP 394 [1] aims to document our collective recommendation for
allowing shebang lines to specifically request some version of 2.x,
without requiring that it be exactly 2.7 (or 2.6, etc).
I'd let this drift for a while, but the imminent release of 2.7.3
makes it necessary to push for a final pronou
73 matches
Mail list logo
