[Python-Dev] Comparison operators (> < >= <=) for collections.Counter
I noticed that collections.Counter, unlike set, doesn't support the ordered comparison operators (> < >= <=). I'd like to propose implementing these operators in an analogous fashion to set: counter1 >= counter2 if counter1 contains at least as many of every key as counter2 does. Cases where counter1 doesn't have a key and counter2 has a negative amount of that key would still count as >=. counter1 > counter2 when counter1 >= counter2 and counter1 != counter2. Does this sound reasonable? If so I'll write up and submit a patch. - Kerrick ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 accepted
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:44 AM, Nick Coghlan wrote: > 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 | Brisbane, Australia > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)
I'm indifferent either way. python3 is a hard link to python3.2, so I thought we'd make everything that way for consistency. Higher-level links (python/idle/pydoc/python-config) have to be soft links so that if, e.g., python points to python3, and python3 is then pointed to another location, python also gets changed. -Kerrick Staley ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)
I put up a tracker issue at http://bugs.python.org/issue12627 There are patches for 2.7 as well as tip, but they only fix the Makefiles; no changes are done to documentation. Also, Ned, it appears that Python 2.7 doesn't install the Idle or PyDoc binaries (grep the 2.7 Makefile to see what I mean), so I didn't make any changes related to idle2 or pydoc2. -Kerrick Staley On Wed, Jul 20, 2011 at 3:28 AM, Nick Coghlan wrote: > > On Wed, Jul 20, 2011 at 4:53 PM, Kerrick Staley > wrote: > > Nick, can you please apply the patch (will be sent in the following > > email) to the PEP SVN as soon as we get the hard-link issue is figured > > out? Alternatively, could you provide me write access to just the > > pep-0394.txt file so I can update it myself? Thanks. > > Done: http://www.python.org/dev/peps/pep-0394/ > > Main thing needed now is a tracker issue to reference (ideally with a > first cut at a patch) and python-dev's collective blessing to take it > out of Draft status. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)
On Wed, Jul 20, 2011 at 3:28 AM, Nick Coghlan wrote: > Done: http://www.python.org/dev/peps/pep-0394/ Quick question: When I do "svn up", it doesn't show any changes. Has it been switched over to Mercurial recently? Thanks, Kerrick Staley ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)
$ svn diff Index: pep-0394.txt === --- pep-0394.txt(revision 88866) +++ pep-0394.txt(working copy) @@ -1,5 +1,5 @@ PEP: 394 -Title: The "python" command on Unix-Like Systems +Title: The "python" Command on Unix-Like Systems Version: $Revision$ Last-Modified: $Date$ Author: Kerrick Staley , @@ -53,10 +53,14 @@ * When reinvoking the interpreter from a Python script, querying ``sys.executable`` to avoid hardcoded assumptions regarding the interpreter location remains the preferred approach. +* The ``idle``, ``pydoc``, and ``python-config`` binaries from Python 2.0 +should likewise be available as ``idle2``, ``pydoc2``, and ``python2-config``, +with the original commands invoking these binaries by default, but possibly +invoking the Python 3.0 versions instead. These recommendations are the outcome of the relevant python-dev discussion in -March 2011 [1] (NOTE: More accurately, they will be such once that "Draft" -status disappears from the PEP header, it has been moved into the "Other +March to July 2011 [1] (NOTE: More accurately, they will be such once that +"Draft" status disappears from the PEP header, it has been moved into the "Other Informational PEP" section in PEP 0 and this note has been deleted) @@ -142,13 +146,21 @@ Application to the CPython Reference Interpreter -While technically a new feature, the ``make install`` command and the Mac OS -X installer in the 2.7 version of CPython will be adjusted to create the -new ``python2`` command in addition to the existing ``python`` and -``python2.7`` commands. This feature will first appear in CPython 2.7.2. +While technically a new feature, the ``make install`` command and the Mac +OS X installer in the 2.7 version of CPython will be adjusted to create the +``python2.7``, ``idle2.7``, ``pydoc2.7``, and ``python2.7-config`` binaries, +with ``python2``, ``idle2``, ``pydoc2``, and ``python2-config`` as links to +the respective binaries. On Mac OS X, these will be symbolic links; on other +platforms, they will be hard links, because hard links improve performance +on filesystems other than Mac OS X's HFS. ``python``, ``idle``, ``pydoc``, +and ``python-config`` will be created as symbolic links to these links. +This feature will first appear in CPython 2.7.2. -The ``make install`` command in the CPython 3.x series will continue to -install only the ``python3`` symlink for the foreseeable future. +The ``make install`` command in the CPython 3.x series will similarly install +the ``python3.x``, ``idle3.x``, ``pydoc3.x``, and ``python3.x-config`` binaries +(with appropriate ``x``), and ``python3``, ``idle3``, ``pydoc3``, and +``python3-config`` as symbolic links on Mac OS X and as hard links on other +platforms. Impact on PYTHON* Environment Variables @@ -166,27 +178,12 @@ Exclusions of MS Windows -This PEP deliberately excludes any proposals relating to Microsoft Windows. -The use of parallel installs on Windows suffers from numerous issues, -including the "last installed wins" behaviour for handling of file -associations, a lack of universal robust symlink support for easy aliasing of -commands, the fact that the Python executable is not available on ``PATH`` by -default, the fact that the ``python.exe`` and ``pythonw.exe`` names are -used for both Python 2 and Python 3 binaries and the lack of distinction -between the different Python versions when the Start menu shortcuts are -divorced from their containing folders (e.g. when they appear in the -"Recently Used" list. +This PEP deliberately excludes any proposals relating to Microsoft Windows: +devising an equivalent solution for Windows was deemed too complex to handle +here. PEP 397 and the related discussion on the python-dev mailing list address +this issue. -While these questions are well worth addressing, they do not have easy -answers. The authors of this particular PEP aren't inclined to even begin -trying to answer them, but anyone that wants to tackle them should feel free -to start working on their own PEP. -Note that, while the topic has been excluded from this PEP, there is plenty of -material in the linked python-dev discussion that may be useful in the design -and implementation of a Windows-specific solution. - - References == ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)
On Mon, Jul 18, 2011 at 3:03 AM, Ned Deily wrote: > I think adding the requirement to mandate hard link vs soft link usage > is an unnecessary and unwarranted attempt at optimization. For > instance, IIRC, the OS X installers don't use any hard links: that may > complicate the install, plus hard links on OS X HFS* file systems are a > bit of a kludge and not necessarily more efficient than symlinks. It's > not a big deal but perhaps the wording should be changed to make a > suggestion about hard links vs syminks rather than mandate which should > be used. Ah, OK. The wording's been changed so that symbolic links will be installed on Mac OS X and hard links elsewhere (although maybe symbolic links are also better on certain other platforms; I'm not sure). I do think that specific instructions must be given (rather than just a suggestion) because it's indicating what must be done to CPython. The instructions *should* be as close as possible to what the installer already does, but I'm not entirely sure what the installer does by default, and the hard-link recommendation was based off a cursory inspection of my own system, so further input from yourself and the rest of python-dev would be appreciated. Nick, can you please apply the patch (will be sent in the following email) to the PEP SVN as soon as we get the hard-link issue is figured out? Alternatively, could you provide me write access to just the pep-0394.txt file so I can update it myself? Thanks. -Kerrick Staley ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)
Hi, These are two emails I sent a short while ago about finalizing PEP 394. There was no response, so in case the messages didn't go through, I'm resending them. Thanks, Kerrick Staley -- Forwarded message ------ From: Kerrick Staley Date: Sat, Jul 9, 2011 at 7:45 PM Subject: Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream To: python-dev@python.org Sorry that I dropped the ball on this. I'd still like to see this get implemented, but I got distracted with school and forgot about it. Updates I have made to the PEP will be sent as a patch immediately after this email. Here's a summary of what was happenening when we left off: * The draft SVN version from March 4 was pretty much complete. * Some were concerned about addressing Windows, but it was generally agreed to leave the Windows issue to another PEP. PEP 397 was started on March 15 to address the Windows side of the issue. PEP 397 recommends that the Windows Python launcher read the shebang and use it to determine which Python version to use; this allows one syntax for both operating systems that is compatible with the current PEP 394 recommendation. * There were concerns from Ned Deily about the naming of other binaries such as idle, pydoc, and python-config; these need to be created as idle2, pydoc2, and python2-config, with links created at the locations of the original binaries. * There were concerns from Glenn Linderman that the shebang line doesn't encode enough information to flexibly handle Windows launching (or even launching in general). Here are my thoughts: * For Ned's comments, I agree. Although the issue isn't as large with these programs, there's no reason we can't handle them in the same way. I updated the PEP. * For Glenn's comments, I think the method you propose adds too much complexity. Regardless, if the #@ syntax is implemented, it can be described in PEP 397; it won't have an impact on the contents of this PEP. I think, though, that having multiple syntaxes may cause many scripts to be incompatible with multiple platforms when they don't have to be, since Unix coders will rarely add a #@ line, and Windows coders will likely forget the #! line. Also, #@ really ignores the purpose of a shebang: shebangs simply indicate an interpreter that works with the script; the shebang allows users to run arbitrary scripts without worrying about which interpreter they should specify. There's no reason that a script should use one interpreter on Unix, but be incompatible with that interpreter on Windows yet compatible with another. The name of the Unix binary is enough to determine the implementation and version of the interpreter to be used on Unix, and a Windows launcher should always invoke the same implementation/version on Windows (and this won't require hard-coding anything into the launcher if done right). If you want the script to run with a specific interpreter and version, possibly contingent on which operating system you're running the script under, then you can just invoke the interpreter by name with the script as an argument (e.g. python3 myprogram.py). TL;DR: shebangs encode a default implementation/version, and if you need something special, you can just manually run python3 myprogram.py or use a .bat file. Also, I updated the PEP with the clarification that commands like python3 should be hard links (because they'll be invoked from code and are more efficient; also, hard links are just as flexible as symlinks here), while commands like python should be soft links (because this makes it clear to sysadmins that they can be "switched", and it's needed for flexibility if python3 changes). This really doesn't matter, but can we keep it this way unless there are serious objections? Regards, Kerrick Staley -- Forwarded message -- From: Kerrick Staley Date: Sat, Jul 9, 2011 at 7:46 PM Subject: Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream To: python-dev@python.org $ svn diff Index: pep-0394.txt === --- pep-0394.txt(revision 88860) +++ pep-0394.txt(working copy) @@ -1,5 +1,5 @@ PEP: 394 -Title: The "python" command on Unix-Like Systems +Title: The "python" Command on Unix-Like Systems Version: $Revision$ Last-Modified: $Date$ Author: Kerrick Staley , @@ -53,10 +53,14 @@ * When reinvoking the interpreter from a Python script, querying ``sys.executable`` to avoid hardcoded assumptions regarding the interpreter location remains the preferred approach. +* The ``idle``, ``pydoc``, and ``python-config`` binaries from Python 2.0 +should likewise be available as ``idle2``, ``pydoc2``, and ``python2-config``, +with the original commands invoking these binaries by default, but possibly +invoking the Python 3.0 versions instead. These re
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
$ svn diff Index: pep-0394.txt === --- pep-0394.txt(revision 88860) +++ pep-0394.txt(working copy) @@ -1,5 +1,5 @@ PEP: 394 -Title: The "python" command on Unix-Like Systems +Title: The "python" Command on Unix-Like Systems Version: $Revision$ Last-Modified: $Date$ Author: Kerrick Staley , @@ -53,10 +53,14 @@ * When reinvoking the interpreter from a Python script, querying ``sys.executable`` to avoid hardcoded assumptions regarding the interpreter location remains the preferred approach. +* The ``idle``, ``pydoc``, and ``python-config`` binaries from Python 2.0 +should likewise be available as ``idle2``, ``pydoc2``, and ``python2-config``, +with the original commands invoking these binaries by default, but possibly +invoking the Python 3.0 versions instead. These recommendations are the outcome of the relevant python-dev discussion in -March 2011 [1] (NOTE: More accurately, they will be such once that "Draft" -status disappears from the PEP header, it has been moved into the "Other +March to July 2011 [1] (NOTE: More accurately, they will be such once that +"Draft" status disappears from the PEP header, it has been moved into the "Other Informational PEP" section in PEP 0 and this note has been deleted) @@ -144,11 +148,16 @@ While technically a new feature, the ``make install`` command and the Mac OS X installer in the 2.7 version of CPython will be adjusted to create the -new ``python2`` command in addition to the existing ``python`` and -``python2.7`` commands. This feature will first appear in CPython 2.7.2. +``python2.7``, ``idle2.7``, ``pydoc2.7``, and ``python2.7-config`` binaries, +with ``python2``, ``idle2``, ``pydoc2``, and ``python2-config`` as hard links +to the respective binaries, and ``python``, ``idle``, ``pydoc``, and +``python-config`` as symbolic links to the respective hard links. This feature +will first appear in CPython 2.7.2. -The ``make install`` command in the CPython 3.x series will continue to -install only the ``python3`` symlink for the foreseeable future. +The ``make install`` command in the CPython 3.x series will similarly install +the ``python3.x``, ``idle3.x``, ``pydoc3.x``, and ``python3.x-config`` binaries +(with appropriate ``x``), and ``python3``, ``idle3``, ``pydoc3``, and +``python3-config`` as hard links. Impact on PYTHON* Environment Variables @@ -166,27 +175,12 @@ Exclusions of MS Windows -This PEP deliberately excludes any proposals relating to Microsoft Windows. -The use of parallel installs on Windows suffers from numerous issues, -including the "last installed wins" behaviour for handling of file -associations, a lack of universal robust symlink support for easy aliasing of -commands, the fact that the Python executable is not available on ``PATH`` by -default, the fact that the ``python.exe`` and ``pythonw.exe`` names are -used for both Python 2 and Python 3 binaries and the lack of distinction -between the different Python versions when the Start menu shortcuts are -divorced from their containing folders (e.g. when they appear in the -"Recently Used" list. +This PEP deliberately excludes any proposals relating to Microsoft Windows: +devising an equivalent solution for Windows was deemed too complex to handle +here. PEP 397 and the related discussion on the python-dev mailing list address +this issue. -While these questions are well worth addressing, they do not have easy -answers. The authors of this particular PEP aren't inclined to even begin -trying to answer them, but anyone that wants to tackle them should feel free -to start working on their own PEP. -Note that, while the topic has been excluded from this PEP, there is plenty of -material in the linked python-dev discussion that may be useful in the design -and implementation of a Windows-specific solution. - - References == ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
Sorry that I dropped the ball on this. I'd still like to see this get implemented, but I got distracted with school and forgot about it. Updates I have made to the PEP will be sent as a patch immediately after this email. Here's a summary of what was happenening when we left off: * The draft SVN version from March 4 was pretty much complete. * Some were concerned about addressing Windows, but it was generally agreed to leave the Windows issue to another PEP. PEP 397 was started on March 15 to address the Windows side of the issue. PEP 397 recommends that the Windows Python launcher read the shebang and use it to determine which Python version to use; this allows one syntax for both operating systems that is compatible with the current PEP 394 recommendation. * There were concerns from Ned Deily about the naming of other binaries such as idle, pydoc, and python-config; these need to be created as idle2, pydoc2, and python2-config, with links created at the locations of the original binaries. * There were concerns from Glenn Linderman that the shebang line doesn't encode enough information to flexibly handle Windows launching (or even launching in general). Here are my thoughts: * For Ned's comments, I agree. Although the issue isn't as large with these programs, there's no reason we can't handle them in the same way. I updated the PEP. * For Glenn's comments, I think the method you propose adds too much complexity. Regardless, if the #@ syntax is implemented, it can be described in PEP 397; it won't have an impact on the contents of this PEP. I think, though, that having multiple syntaxes may cause many scripts to be incompatible with multiple platforms when they don't have to be, since Unix coders will rarely add a #@ line, and Windows coders will likely forget the #! line. Also, #@ really ignores the purpose of a shebang: shebangs simply indicate an interpreter that works with the script; the shebang allows users to run arbitrary scripts without worrying about which interpreter they should specify. There's no reason that a script should use one interpreter on Unix, but be incompatible with that interpreter on Windows yet compatible with another. The name of the Unix binary is enough to determine the implementation and version of the interpreter to be used on Unix, and a Windows launcher should always invoke the same implementation/version on Windows (and this won't require hard-coding anything into the launcher if done right). If you want the script to run with a specific interpreter and version, possibly contingent on which operating system you're running the script under, then you can just invoke the interpreter by name with the script as an argument (e.g. python3 myprogram.py). TL;DR: shebangs encode a default implementation/version, and if you need something special, you can just manually run python3 myprogram.py or use a .bat file. Also, I updated the PEP with the clarification that commands like python3 should be hard links (because they'll be invoked from code and are more efficient; also, hard links are just as flexible as symlinks here), while commands like python should be soft links (because this makes it clear to sysadmins that they can be "switched", and it's needed for flexibility if python3 changes). This really doesn't matter, but can we keep it this way unless there are serious objections? Regards, Kerrick Staley ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
I think that at this point there's been sufficient agreement that the technical issues on Windows are too complex to warrant addressing them in this PEP, and that a separate PEP will be written addressing Windows, so that is what will happen. A new email thread for the Windows topic should be started so that the discussions can be separated, and those uninterested in the Windows question can stop following that discussion without missing Unix-related comments buried in it. -Kerrick Staley ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
> Heh, you are the author of the PEP :-) > You'll find the source of your PEP in > http://svn.python.org/projects/peps/trunk/ > Please provide Nick with a patch/updated version; if you want to, > you can also get write access to the PEP repository. I should've mentioned that I'd like a consensus (or a lack of protest) on the changes related to these snippets: -"python will refer to the same target as either python2 or python3, depending on the specific distribution and system" -"the make install command and the Mac OS X installer in the 2.7 version of CPython will be adjusted to create the new python2 command in addition to the existing python and python2.7 commands" -"Exclusions of MS Windows" The other changes are in the attached diff. The source needs to be reflown if line length is to be kept consistent. I don't feel I need write access to the repository at this point. -Kerrick Staley --- pep-0394.txt2011-03-05 01:06:50.0 -0600 +++ pep-0394-revised.txt2011-03-06 15:07:42.37338 -0600 @@ -1,5 +1,5 @@ PEP: 394 -Title: The "python" command on Unix-Like Systems +Title: The "python" Command on Unix-Like Systems Version: $Revision$ Last-Modified: $Date$ Author: Kerrick Staley , @@ -37,11 +37,7 @@ * 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``. -* For the time being, it is recommended that ``python`` should refer to - ``python2``, except on distributions which include only ``python3`` in their - base install, or those that wish to push strongly for migration of user - scripts to Python 3. -* In order to tolerate differences across platforms, all new code that needs +* In order to tolerate differences across platforms, all code that needs to invoke the Python interpreter should not specify ``python``, but rather should specify either ``python2`` or ``python3`` (or the more specific ``python2.x`` and ``python3.x`` versions; see the Notes). @@ -68,7 +64,7 @@ ``python`` command to Python 2, some now alias it to Python 3. Some of the former also do not provide a ``python2`` command; hence, there is currently no way for Python 2 code (or any code that invokes the Python 2 -interpreter directly rather than via ``sys.executable``) to reliably run on +interpreter) to reliably run on all systems without modification, as the ``python`` command will invoke the wrong interpreter version on some systems, and the ``python2`` command will fail completely on others. The recommendations in this PEP provide a very @@ -113,9 +109,10 @@ ``python`` file, they can do so without inadvertently deleting the previously installed binary. * As an alternative to the recommendation presented above, some distributions - may choose to leave the ``python`` command itself undefined, leaving - sysadmins and users with the responsibility to choose their own preferred - version to be made available as the ``python`` command. + that have traditionally left the ``python`` command undefined may continue + to do so, leaving + sysadmins and users with the responsibility of making their own preferred + version available as the ``python`` command. * If the Python 2 interpreter becomes uncommon, scripts should nevertheless continue to use the ``python3`` convention rather that just ``python``. This will ease transition in the event that yet another major version of Python ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
Sorry, I was unaware that Gmail splits threads that are longer than 100 messages, so I hadn't seen the last 26 messages when I wrote the above message. It seems that in the last 26 messages, there was lots of discussion toward the inclusion of provisions for Windows in this PEP. I didn't mean to silence those opinions, so I retract the part about Windows in my last message and instead defer the decision to the rest of you, since I don't care too strongly about it. I sometimes neglect to throw an "I think" into a sentence when I really should. However, I would still like to suggest in the softest of ways that, since it seems that the issues on Windows are complex and multiple possible solutions must be evaluated, it may be best to finalize this PEP and then start work on another one that addresses the issue on Windows. Also, there may not be enough commonality between the solutions on the two platforms to justify keeping the solutions in the same document. Kerrick Staley ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
Some nitpicks: 'The "python" command on Unix-Like Systems': This should be 'The "python" Command on Unix-Like Systems' "python will refer to the same target as either python2 or python3, depending on the specific distribution and system": Nothing should break if python isn't the same as either python2 or python3 (sysadmins might want to set something like this up), so let's change it to "python will refer to some version of either Python 2.x or Python 3.x". Similarly, "the same version of Python as either python2 or python3" should be "some version of either Python 2.x or Python 3.x". "For the time being, it is recommended that python should refer to python2, except on distributions which include only python3 in their base install, or those that wish to push strongly for migration of user scripts to Python 3.": This bullet should be removed, since it unnecessarily lengthens the Recommendation (the same topic is addressed in the first bullet of the Notes) and is intended to be less strongly suggested than the other points in the Recommendation. "...all new code...": take out "new"; we would also like existing code to be modified when possible. "the make install command and the Mac OS X installer in the 2.7 version of CPython will be adjusted to create the new python2 command in addition to the existing python and python2.7 commands": Are we going to specify which is the symbolic link and which is the actual executable? Per the 5th point in the Notes, I think that python should be a symlink (does the default installer do this already, placing the executable in pythonX.X?), since creating it as a link has advantages over an executable in certain situations, but the reverse is not true. "directly rather than via sys.executable": This snippet is unneeded and confusing, because the "or any code that invokes the Python 2 interpreter" parenthetical note is intended to address code in other languages that execute the interpreter and not Python code. "As an alternative to the recommendation presented above, some distributions may choose to leave the python command itself undefined, leaving sysadmins and users with the responsibility to choose their own preferred version to be made available as the python command.": The original version of this statement only addressed systems that have traditionally left python undefined (OpenBSD apparently does this). As it's worded now, it creates the possibility that distributions will suddenly start leaving python undefined as a result of this PEP, to the vexation of end-users. The "Exclusions of MS Windows" section should be shortened to "This PEP deliberately excludes any proposals relating to Microsoft Windows, due to multiple issues in implementing a similar solution." This is because this PEP is about the solution on Unix-Like systems; the discussion of the issue on other platforms adds unnecessary length. The ideas in this section are preserved in this discussion thread (which is referenced in the PEP) and the verbatim text will still exist in the SVN, so anyone who needs this information can still get it easily if it is deleted. Although I am unfamiliar with Windows and am thus unaware of all the issues and possible solutions, I think that an excellent solution for the Python 2/3 issue on Windows was that suggested by Michael Foord: "...a stub python.exe that looks at the shebang line and then delegates to the appropriate pythonX.Y.exe would be a possibility..." However, implementing this solution will take time and will slow the finalization of a solution for Unix-like systems if it is included in this PEP. -Kerrick Staley ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream
> Right, but on Mac OS X we do put a "python3" on the path but not a "python2". We also > create "python2.x" and "python3.x" variants. The PEP makes a recommendation for all *nix platform, which includes Mac OS X. I was not aware that Apple preinstalled Python on OS X, but it doesn't really matter: Apple is the "distribution maintainer", and they will be expected to follow the recommendations of this PEP. Even if Apple is sluggish in getting this change pushed out, it can be resolved on a per-system basis by the sysadmin. > On Windows we only have a "python.exe" I believe, but if the user does put their Python > installs on the path then we *could* usefully create "python2.exe" and "python3.exe" for > them. I don't see that duplicating these binaries on the filesystem is an issue. File > associations is just unsolvable on Windows, so it isn't something we can address or should > worry about. (Actually a stub python.exe that looks at the shebang line and then > delegates to the appropriate pythonX.Y.exe would be a possibility but I'm not > volunteering to write it.) I like your idea for Windows, but it would take time to implement this solution, and we won't be able to finalize the solution for *nix as quickly if we also provide a provision for Windows in this same PEP. We should keep the use of the singular "they"; it's more popular than the universal "he" (I intended the universal, rather than gender-specific, meaning in the drafts of the PEP). -Kerrick Staley On Fri, Mar 4, 2011 at 9:50 AM, Ronald Oussoren wrote: > > > On 04 Mar, 2011,at 02:21 PM, Nick Coghlan wrote: > > > For *nix, I think there is a simple way forward that is an improvement > over where things stand now. For Windows, I don't think we can do much > better than the status quo and for Mac OS X... I think Apple will do > whatever Apple feel like doing :) > > > Apple will generally follow what we decide to do for the base install. > > Anyway, I'd say that OSX should do the same as Unix platforms here and > support '#!/usr/bin/env python2'. Adding another symlink is fairly trivial. > > Ronald > > P.S. I'm a bit confused about this discussion though, wouldn't adding > python2 to the installation be a feature change and as such not something > that can be done in a maintenance branch? > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream
PEP: ??? Title: The python Utility on Unix-Like Systems Version: ??? Last-Modified: ??? Author: Kerrick Staley Status: Draft Type: Informational Content-Type: text/x-rst Created: 02-Mar-2011 Post-History: ??? Abstract == This PEP provides a convention to ensure that Python scripts can continue to be portable across *nix systems, regardless of the default version of the Python interpreter (i.e. the version invoked by the "python" utility). Recommendation * ``*nix`` software distributions should install the "python2" utility into the default path whenever a version of the Python 2 interpreter is installed, and the same for "python3" and the Python 3 interpreter. When invoked, "python2" should run some version of the Python 2 interpreter, and "python3" should run some version of the Python 3 interpreter. The same applies for the more general "python" command, which should should be installed whenever any version of Python is installed and should invoke some Python interpreter. * All new code that needs to invoke the Python interpreter should not specify "python", but rather should specify either "python2" or "python3" (or the more specific "python2.X" and "python3.X" versions; see the Notes). This distinction should be made in shebangs, when invoking from a shell script, when invoking via the system() call, or when invoking in any other context. Rationale === This is needed because some distributions alias the "python" command to Python 3, while others alias it to Python 2. Some of the latter also do not provide a "python2" command; hence, there is no way for Python 2 code (or any code that invokes the Python 2 interpreter) to reliably run on all systems without modification, because both the "python" and the "python2" commands will fail on some systems. The recommendations in this PEP provide a very simple mechanism to restore cross-platform support, with very little additional work required on the part of distribution maintainers. Notes === * Distributions can alias the "python" command to whichever version of the Python interpreter they choose. * The "pythonX.X" (e.g. "python2.6") utilities exist on some systems, on which they invoke specific minor versions of the Python interpreter. It would be wise for distribution-specific packages to take advantage of these utilities if they exist, since it will prevent code breakage if the default minor version of a given major version is changed. However, scripts intending to be cross-platform should not rely on the presence of these utilities, but rather should be tested on several recent minor versions of the target major version, compensating, if necessary, for the small differences that exist between minor versions. This prevents the need for sysadmins to install many very similar versions of the interpreter. * It would be wise for distribution-specific packages to always follow the "python2"/"python3" convention, even in code that is not intended to operate on other distributions. This will prevent problems if the distribution decides to upgrade the version of the Python interpreter that the "python" command invokes, or if the sysadmin installs a custom "python" utility with a different major version than the distribution default. Distributions can test whether they are fully following this convention by changing the "python" interpreter on a test box and checking to see if anything breaks. * If the above point is adhered to and sysadmins are permitted to change the "python" utility, then the "python" utility should always be implemented as link to the interpreter binary (or a link to a link) and not vice versa. That way, if the sysadmin does decide to replace the installed "python" file, he can do so without inadvertently deleting the previously installed binary. * The first recommendation can be ignored for systems on which the "python" command itself has traditionally been left undefined and users have always had the responsibility of linking the "python" command to the Python interpreter. * If the Python 2 interpreter becomes uncommon, scripts should nevertheless continue to use the "python3" convention rather that just "python". This will ease transition in the event that yet another major version of Python is released. * If these conventions are adhered to, it will be the case that the "python" utility is only executed in an interactive manner. Backwards Compatibility = A potential problem can arise if a script adhering to the "python2"/"python3" convention is executed on a system not supporting these commands. This is mostly a non-issue, since the sysadmin c
Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream
> LGTM. Please specify what /usr/bin/python is supposed to be also
> (rather: the "python" utility). I'd like it ruled out that
> installations *only* provide python2 and python3 - "python" could
> be either one, but should be present "normally" (i.e. SHOULD
> in the RFC 2119 sense).
>
> Nitpickingly, I'd add that scripts can, of course, also specify
> python2.7 (or some such). Actually, scripts can do whatever they
> want - it's more about what they then can expect to happen.
Good points--I've taken them into account in the revised PEP, which I will
send to this list shortly.
> OTOH, my
> cynical side doubts that script authors read PEPs so it'll take either
> upstream python shipping without /usr/bin/python or consensus among the
> distros to ship without /usr/bin/python to reach the point where script
> authors realize that they need to use /usr/bin/python{2,3} instead of
> /usr/bin/python.
I don't see this as an issue: all it will take is for one user with a
different "python" to contact a developer once, referring the developer to
the PEP, and then every program that that developer ever writes in the
future will be fixed (and, if the developer's worth anything, every program
he's already written, as well). Word of mouth tends to pass these things
around quickly.
> Actually, I think this is *not* a good idea for distro provided scripts.
For
> any Python scripts released by the distro, you know exactly which Python
it
> should run on, so it's better to hard code it. That way, if someone
installs
> Python from source, or installs an experimental version of a new distro
> Python, it won't break their system.
I agree. I would personally like it if distributions would provide a python
utility that can be changed by the sysadmin without breaking anything, but
implementing such a thing would be too much to ask from many distros, so I
left it out of the first draft of the PEP. I'll put into the Notes in the
second draft, though.
Again, I think that the nature of the "python" utility is a decision that
belongs squarely to the distributions (it'll likely evolve into an "everyone
else is doing it" sort of issue for distros like Debian that don't like to
change without good reason). On the other hand, ensuring that cross-platform
support exists is an issue that should be handled by a central authority.
I almost added provisions to the second draft of the PEP for things like
"python2.6", since the same issue basically exists with them, so it would be
logical to also address their support. However, since there are far fewer
cases where minor version changes break code, and far more cases where a
specific minor version of the Python interpreter isn't and doesn't need to
be installed, I imagine a problem will occur if we make "pythonX.X"
standard: developers will use the "pythonX.X" invocations instead of
ensuring their code works on all (recent) versions of the interpreter, and
much larger issues will arise when users are forced to repeatedly install
different minor versions of the interpreter. I instead addressed this topic
in the "Notes" section.
-Kerrick Staley
On Thu, Mar 3, 2011 at 10:09 PM, Toshio Kuratomi wrote:
> On Thu, Mar 03, 2011 at 09:11:40PM -0500, Barry Warsaw wrote:
> > On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:
> >
> > >On a related note, we have a number of scripts packaged across the
> > >distributions with a shebang line that reads:
> > > #!/usr/bin/env python
> > >which AIUI follows upstream recommendations.
> >
> > Actually, I think this is *not* a good idea for distro provided scripts.
> For
> > any Python scripts released by the distro, you know exactly which Python
> it
> > should run on, so it's better to hard code it. That way, if someone
> installs
> > Python from source, or installs an experimental version of a new distro
> > Python, it won't break their system. Yes, this has happened to me.
> Also,
> > note that distutils/setuptools/distribute rewrite the shebang line when
> they
> > install scripts.
> >
> > >There was a proposal to change these when packaging them to hardcode the
> > >specific python binary:
> > >
> > >
> https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
> > >on the grounds that a packaged system script is expecting (and has been
> > >tested against) a specific python build.
> > >
> > >That proposal has not yet been carried out. Ideally if we did this,
> > >we'd implement it as a postprocessing phase within "rpmbuild", rather
> > >than manually patchin
Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream
The point is that there never has to be an agreement about the python command, as long as all distros support python2/python3 and all scripts use it (I think that the distinction should continue to be made if/when python2 becomes uncommon, otherwise we'll hit the same issue with python4). We don't have to force anyone to change the python command itself. That being said, I feel that the python command should only be invoked from an interactive terminal, and in fact it would be good if distros would use the python2/python3 convention in their own packages, so that the sysadmin can point python to wherever he wants, and when he types python into a terminal get the version he wants. As an added plus, should a distro supporting this feature decide to make the Python 2 -> Python 3 switch, it would be an effortless process. Again, however, force this requirement shouldn't be forced on distros. As an aside, this whole thing started when I tried installing ROS<http://www.ros.org/wiki/>, only to find that it made assumptions about /usr/bin/python, which points to python3 on my Arch Linux system. I went in search of documentation for the python2/python3 convention so that I could make the ROS developers aware of it and help them to follow it, only to find out that no such convention actually exists. Since ROS uses a rather complicated python-based installer that makes assumptions about /usr/bin/python not only in the shebangs of many files but also in other places (apparently in connection with the subprocess module), it has proven thus far unworkable unless I change /usr/bin/python back to Python 2, a move that could potentially break many other aspects of my system. I'm sure there are many other users out there that are frustrated by similar issues; supporting a python2/python3 convention on all distros as well as in scripts would solve these issues without creating further problems and without the need for a slow consensus to be reached on what /usr/bin/python should be. Here is a draft PEP (forgive me if it's incorrectly formatted; I've never done this before). I think it's a little long winded given how simple the idea it proposes is, but I thought it would be better to be more specific than necessary rather than less. . PEP: ??? Title: The python Command on Unix-Like Systems Version: ??? Last-Modified: ??? Author: Kerrick Staley Status: Draft Type: Informational Content-Type: text/x-rst Created: 02-Mar-2011 Post-History: ??? Abstract == This PEP provides a convention to ensure that Python scripts can continue to be portable across *nix systems, regardless of the default version of the Python interpreter (i.e. the version invoked by the "python" command). Recommendation * ``*nix`` software distributions should install the command "python2" into the default path whenever a version of the Python 2 interpreter is installed, and the same for "python3" and the Python 3 interpreter. When invoked, "python2" should run some version of the Python 2 interpreter, and "python3" should run some version of the Python 3 interpreter. * All new code that needs to invoke the Python interpreter should specify either "python2" or "python3", according to the version it requires, but not "python". This distinction should be made in shebangs, when invoking from a shell script, when invoking via the system() call, or when invoking in any other context. Rationale === This is needed because some distributions alias the "python" command to Python 3, while others alias it to Python 2. Some distributions also do not provide a "python2" command; hence, there is no way for Python 2 code (or any code that invokes the Python 2 interpreter) to reliably run on all systems without modification, because both the "python" and the "python2" commands will fail on some systems. The recommendations in this PEP provide a very simple mechanism to restore cross-platform support, with very little additional work required on the part of distribution maintainers. Notes === * Distributions can alias the "python" command to whichever version of the Python interpreter they choose. * It would be wise for distributions to always follow the convention that this PEP recommends, even in code that is not intended to operate on other distributions. This will make it easier if the code ever needs to be ported to another distribution or if the distribution decides to change the version of the Python interpreter that the "python" command invokes. Distributions can test whether they are fully following this convention by switching the "python" interpreter and seeing if anything breaks. * If the above point is adhered to, then the "python" command should always be a link to the interpreter binary (or a link to a link) a
Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream
I think that it's a good idea to not only state that python should be Python 2, but also that python2 should be implemented and that scripts should specify it, to provide redundancy and handle distros that won't or have not yet switched back to the python -> python2 convention. I've . In any event, I do agree that there needs to be a clear standard coming from the Python community. Should I submit a PEP for this? I'm also going to talk to the Arch devs and ask them to follow these proposed standards (or at least to allow python to be user-switchable). Thanks, Kerrick Staley On Tue, Mar 1, 2011 at 4:15 PM, James Y Knight wrote: > > On Mar 1, 2011, at 5:06 PM, Guido van Rossum wrote: > > > On Tue, Mar 1, 2011 at 1:26 PM, Eric Smith wrote: > >> On 3/1/2011 4:19 PM, Kerrick Staley wrote: > >>> > >>> Hello, > >>> There is a need for the default Python2 install to place a symlink at > >>> /usr/bin/python2 that points to /usr/bin/python, or for the > >>> documentation to recommend that packagers ensure that python2 is > >>> defined. Also, all documentation should be changed to recommend that > >>> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts. > >>> This is needed because some distributions (Arch Linux, in particular), > >>> point /usr/bin/python to /usr/bin/python3, while others (including > >>> Slackware, Debian, and the BSDs, probably more) do not even define the > >>> python2 command. This means that a script has no way of achieving > >>> cross-platform compatibility. The point at which many distributions > >>> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for > >>> the next couple of years, it would be best to use a python2 or python3 > >>> shebang in all scripts, making no assumptions about plain python, which > >>> should only be invoked interactively. This email from about 3 years ago > >>> seems relevant: : > >>> http://mail.python.org/pipermail/python-3000/2008-March/012421.html > >>> Again, this issue needs to be addressed by the Python developers > >>> themselves so that different *nix distributions will handle it > >>> consistently, allowing Python scripts to continue to be cross-platform. > >>> > >> > >> I believe we agreed at the language summit last year (or maybe even the > year > >> before) that "python" would always be python2.x, and "python3" would be > >> python3.x. > >> > >> And by "always" we indeed meant forever. To do otherwise would break > scripts > >> even many, many years from now. > > > > Unfortunately distros are not following these guidelines. As long as > > we still have the pythonX.Y links I think it's better to have > > "python2", "python3" and "python" than total anarchy. > > If python upstream would make it clear that that *IS* the policy, distros > might follow it. Right now, there is no clear guidance, as far as I can > tell. If you do not want distros making python be a link to python3, please > say so loudly, preferably on a webpage on python.org that users can point > the distros to. > > James > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream
I understand, but is it at least possible to officially recommend that python, python2, and python3 all exist, that distributions point python to python2, and that scripts specify which of python2 and python3 they are using? This would create a redundant system that doesn't avoids problems even if distributions do decide to ignore the second point. If not, can someone point me to official documentation that recommends that python always invoke Python2, so that I can take the case up with the Arch developers? Thanks, Kerrick Staley On Tue, Mar 1, 2011 at 3:26 PM, Eric Smith wrote: > On 3/1/2011 4:19 PM, Kerrick Staley wrote: > >> Hello, >> There is a need for the default Python2 install to place a symlink at >> /usr/bin/python2 that points to /usr/bin/python, or for the >> documentation to recommend that packagers ensure that python2 is >> defined. Also, all documentation should be changed to recommend that >> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts. >> This is needed because some distributions (Arch Linux, in particular), >> point /usr/bin/python to /usr/bin/python3, while others (including >> Slackware, Debian, and the BSDs, probably more) do not even define the >> python2 command. This means that a script has no way of achieving >> cross-platform compatibility. The point at which many distributions >> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for >> the next couple of years, it would be best to use a python2 or python3 >> shebang in all scripts, making no assumptions about plain python, which >> should only be invoked interactively. This email from about 3 years ago >> seems relevant: : >> http://mail.python.org/pipermail/python-3000/2008-March/012421.html >> Again, this issue needs to be addressed by the Python developers >> themselves so that different *nix distributions will handle it >> consistently, allowing Python scripts to continue to be cross-platform. >> >> > I believe we agreed at the language summit last year (or maybe even the > year before) that "python" would always be python2.x, and "python3" would be > python3.x. > > And by "always" we indeed meant forever. To do otherwise would break > scripts even many, many years from now. > > Eric. > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Support the /usr/bin/python2 symlink upstream
Hello, There is a need for the default Python2 install to place a symlink at /usr/bin/python2 that points to /usr/bin/python, or for the documentation to recommend that packagers ensure that python2 is defined. Also, all documentation should be changed to recommend that "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts. This is needed because some distributions (Arch Linux, in particular), point /usr/bin/python to /usr/bin/python3, while others (including Slackware, Debian, and the BSDs, probably more) do not even define the python2 command. This means that a script has no way of achieving cross-platform compatibility. The point at which many distributions begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for the next couple of years, it would be best to use a python2 or python3 shebang in all scripts, making no assumptions about plain python, which should only be invoked interactively. This email from about 3 years ago seems relevant: : http://mail.python.org/pipermail/python-3000/2008-March/012421.html Again, this issue needs to be addressed by the Python developers themselves so that different *nix distributions will handle it consistently, allowing Python scripts to continue to be cross-platform. Thanks, Kerrick Staley ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
