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
$ 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 m...@kerrickstaley.com, @@ -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
On 07/03/2011 21:33, Glenn Linderman wrote: On 3/7/2011 4:00 PM, Michael Foord wrote: On 07/03/2011 23:52, Greg Ewing wrote: Michael Foord wrote: - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if not then python foo.py on the command line will *still* not work... However, if it's installed as the exe associated with the .py and .pyw extensions, then simply 'foo.py' on the command line *will* work, and will work better than it does now. So long as '.py' and '.pyw' are set in the PATHEXT environment variable. (Which again the Python installer doesn't do by default.) No, PATHEXT only means you can invoke foo.py and foo and get the same results (sometimes, depending on what all in on PATH and PATHEXT) You're correct of course. My apologies. Michael Foord ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On 3/9/2011 1:27 AM, Mark Hammond wrote: your position but my personal opinion is that simple support for #! is more desirable. I agree. One weird line in a file is enough! -- Terry Jan Reedy ___ 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
On 9 March 2011 06:27, Mark Hammond mhamm...@skippinet.com.au wrote: I'm glad solving world hunger is out of scope for this :) I understand your position but my personal opinion is that simple support for #! is more desirable. I'd be happy to go with the consensus though... Just in case you need some reassurance about the level of consensus, I agree that simple support for #! is sufficient. Any more is YAGNI. (But if you manage to solve world hunger, do let us know :-)) Paul. ___ 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
Calling it python.exe would make the most sense for people who don't look behind the curtain, but I agree it could potentially be confusing for people. Further, we would need to ensure we didn't create an infinite loop where the launcher python.exe found a python.exe it thought was an appropriate sub-process, but where it turns out it is actually another launcher. Having it installed by the Python installer also makes sense to me but I'd be very interested in Martin's take on this (and also on everything else we are discussing here). I think I would be opposed to adding a launcher to 2.7. It also wouldn't be necessary - if it was released with 3.3, then it could still do version switching for 2.7. If it's called python.exe, I wonder what it should do when given a file that doesn't carry version information. I suspect most people just find it more convenient to launch such scripts from a console. Maybe a quick poll on python-list would be reasonable... I certainly have script files that I double-click. However, those happen to be batch files, not Python. If I would do scripting in Python (which I don't do much these days), I would like to be able to double-click them. I always write my scripts so that they don't give exceptions :-) Actually, the one Python script I run regularly is msi.py, and I currently launch it in a terminal window, because I need to run it with c:\python25\python.exe, which double-clicking won't do for me. If I could double-click it, I would like that more (there is also the issue that the script needs the VS envvars set, so I'd need to find a solution to that, also). Regards, Martin ___ 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
Am 08.03.2011 01:00, schrieb Michael Foord: On 07/03/2011 23:52, Greg Ewing wrote: Michael Foord wrote: - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if not then python foo.py on the command line will *still* not work... However, if it's installed as the exe associated with the .py and .pyw extensions, then simply 'foo.py' on the command line *will* work, and will work better than it does now. So long as '.py' and '.pyw' are set in the PATHEXT environment variable. (Which again the Python installer doesn't do by default.) Running foo.py works fine with the current installers (just try to see for yourself). You don't need PATHEXT for that. Regards, Martin ___ 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
Michael Foord wrote: The launcher program could thrive without *having* to be part of a standard Python install. Offering it separately makes sense even if it *is* included. If we do both then users can vote with their feet. A launcher might be difficult to integrate into the Python installer, as there can, by definition, only be one. What if I install a new version of Python and then uninstall it? Will the launcher be uninstalled as well? Will it be reverted to a previous version, and if so, which? I am actually working on such a launcher for myself right now. The main problem I am trying to solve is doubleclicking a .py or .pyw file and having it run in the Python version it is intended for. From the command line, I want something.py arg1 ... argn to do the right thing as well. I don't care much for fixing python something.py arg1 ... argn, as I personally rarely need to pass options to Python. I may look into that later, though. My launcher parses the first line of the script for something that starts with #! and contains pythonsomething. It tries to match that with a list of installed Python versions obtained from the registry, falling back to a configurable default if no such line is found. As to performance of such a solution: I'm writing this in Python (2.5, as its MSVCRT is easier to include in an exe) and converting it to an executable with py2exe. The extra startup time is manageble on my system. Using Python to write this in makes it much easier to experiment with adding features. Once the dust has settled I may attempt to rewrite it in C. Anyway, I believe that such a launcher should not be part of Python itself at first; an external program makes it easier to figure out what works well. As to adding Python to the Windows path: I'd be mildly annoyed if the installer offered that option, and seriously annoyed if it defaulted that option to yes. Gertjan. ___ 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
After a little investigation, I think what is currently proposed in the PEP is fine for OS X and other systems which use the Unix makefile altinstall and install targets, as far as it goes. However, for completeness, I think the PEP should also cover (most of) the other files that are installed in the bin directory besides python; those are idle, pydoc, and python-config, and 2to3. To allow a clean eventual transition to Python 3 as the default, 2.7.2 should be changed to install the new hard links: python2, idle2, pydoc2, and python2-config. Currently, there are no overlapping filenames in the bin directory between Py2 and Py3 installs except for 2to3. 2to3 is a bit of a special case since it is common between Py2 and Py3; however the version of 2to3 itself differs between releases. As of now, if the standard Makefiles are used, the user will get 2to3 from the Python release for which a make install (or for Python 2.x, a make altinstall as well) has most recently been executed. That might not be the most recent version of 2to3, say, if an older Py2 release is installed after a newer Py3 one. That's not good practice. But that is also outside the scope of the PEP. What is currently added to the installation bin directory for 2.7 and 3.2 is summarized in the table below followed by the proposed changes. Note, the bin directory is typically /usr/bin on Unix-y systems; for Mac OS X framework builds, each Python minor version has its own bin directory within the same base Python framework. 2.73.2 --- ------ --- alt insalt ins --- ------ --- Y Y Y 2to3 Y Y 2to3-3.2 Y 2to3 (symlink to 2to3-3.2) Y Y idle Y Y idle3.2 Y idle3 (symlink to idle3.2) Y Y pydoc Y Y pydoc3.2 Y pydoc3 (symlink to pydoc3.2) Y python (hardlink to python2.7) Y python-config (symlink to python2.7-config) Y Y python2.7 Y Y python2.7-config Y python3 (hardlink to python3.2m) Y python3-config (symlink to python3.2-config) Y Y python3.2 (hardlink to python3.2m) Y python3.2-config (symlink to python3.2m-config) Y Y python3.2m Y Y python3.2m-config Y Y smtpd.py + python2 (hardlink to python2.7) ? idle2 (hardlink to idle) ? pydoc2 (hardlink to pydoc) ? python2-config (hardlink to python-config) X 2to3-2 (no need for 2 versions) alt = installed by make altinstall ins = installed by make install Y = installed m = optional combination of d, m, u + = currently in PEP 394 ? = should be added to PEP 394 X = should not be added -- Ned Deily, n...@acm.org ___ 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
On Tue, Mar 8, 2011 at 03:33, Martin v. Löwis mar...@v.loewis.de wrote: If it's called python.exe, I wonder what it should do when given a file that doesn't carry version information. I would expect it to follow the guidance of the Unix PEP as much as possible. IIRC this means it would launch the highest 2.x version of Python on the system. If there is no 2.x version, it would launch the highest known version (presumably 3.x) for now. I would expect this behavior for any unversioned name of the launcher (e.g. python.exe or pystart.exe). Actually, the one Python script I run regularly is msi.py, and I currently launch it in a terminal window, because I need to run it with c:\python25\python.exe, which double-clicking won't do for me. If I could double-click it, I would like that more (there is also the issue that the script needs the VS envvars set, so I'd need to find a solution to that, also). It's implicit scope creep, but perhaps the launcher could be configured to provide certain environment tweaks, either for all versions of Python, or specific for each version. A more extreme scope creep could allow this information to be stored in the .py file, but that seems backwards to me. To think a bit further on how the launcher should resolve the version, We should probably first see if the #! line works as an executable with optional single argument. This would allow someone to specify overrides like: #! D:\Checkout\...\python If the file doesn't exist, fall back to scanning for python[.exe] with or without a version (in order to support scripts with /usr/bin/python* or /usr/bin/env python*). If it has a version follow the version as closely as possible (map 2 to latest 2.x, 3 to latest 3.x, etc.). If it doesn't have a version, find the latest 2.x or latest any version as above, per the most recent relevant PEP. Open question is what to do if the script clearly requests version 2.6 but only 2.5, 2.7 and 3.2 are installed, or requests 2.x but only 3.x is installed; I could see erroring out as refus[ing] the temptation to guess. -- Michael Urman ___ 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
On Tue, Mar 8, 2011 at 03:40, Gertjan Klein gkl...@xs4all.nl wrote: A launcher might be difficult to integrate into the Python installer, as there can, by definition, only be one. What if I install a new version of Python and then uninstall it? Will the launcher be uninstalled as well? Will it be reverted to a previous version, and if so, which? As long as component rules are maintained (the same components with same GUIDs install the same files in the same locations) and they are marked shared, Windows Installer will handle everything for us. If the files have versions the way Windows Installer can process them, it will even keep the highest version of the file in place. -- Michael Urman ___ 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
On 3/7/2011 2:18 PM, James Y Knight wrote: On Mar 7, 2011, at 3:49 PM, Paul Moore wrote: The launcher could also (as per Mark's suggestion) interpret a shebang line in the script, so that scripts could specify their required version without needing a different command,or multiple version-specific extensions. Note that, on Unix, python file.py doesn't choose the correct version of python to run by looking at a shebang, it just runs the version of python installed as python. Only ./file.py looks at the shebang (assuming that file is marked executable). Is the proposal to make python.exe do that on windows? That is a rather significant difference from the unix behavior. The launcher need not be called python.exe, and maybe it would be better called #@launcher.exe (or similar, depending on its exact function details). For launching from the command line, if various versions python binaries or batch files are on the PATH, then appropriate explicit python invocation python foo.py # Just like Unix python2 foo.py python3 foo.py should launch the specified version (where python may be somewhat ambiguous) but foo.py # with the help of a launcher this could be just like Unix too would implicitly use the launcher, as would launching it from the GUI. There are two problems here, explicit command-line invocation, and GUI/assoc invocation. A launcher need not, and probably should not, do anything for explicit python invocation, but would only solve the implicit and GUI type of invocations. ___ 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
On 3/7/2011 9:31 PM, Reliable Domains wrote: The launcher need not be called python.exe, and maybe it would be better called #@launcher.exe (or similar, depending on its exact function details). I do not know that the '#@' part is about, but pygo would be short and expressive. -- Terry Jan Reedy ___ 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
On 3/8/2011 12:02 PM, Terry Reedy wrote: On 3/7/2011 9:31 PM, Reliable Domains wrote: The launcher need not be called python.exe, and maybe it would be better called #@launcher.exe (or similar, depending on its exact function details). I do not know that the '#@' part is about, but pygo would be short and expressive. If my proposal to make a line starting with #@ to be used instead of the Unix #! (#@ could be on the first or second line, to allow cross-platform scripts to use both, and Windows only scripts to not have #!), then #@launcher.exe (and #@launcherw.exe I suppose) would reflect the functionality of the launcher, which need not be tightly tied to Python, if it uses a separate line. But the launcher should probably not be the thing invoked from the command line, only implicitly when running scripts by naming them as the first thing on the command line. I'm of the opinion that attempting to parse a Unix #! line, and intuit what would be the equivalent on Windows is unnecessarily complex and error prone, and assumes that the variant systems are configured using the same guidelines (which the Python community may espouse, but may not be followed by all distributions, sysadmins, or users). That's why I propose a different line for Windows... it is as simple as the long-proven Unix #! line, but imposes no restrictions on or requirements that there be a #! line; it has more flexibility in that it could invoke different versions or provide different options on Unix and Windows if necessary for some environments. #!/usr/bin/env python2.6 -B #@c:\python26\python2.6.exe or #!/usr/bin/python2.5 #@C:\Program Files (x86)\IronPython 2.6 for .NET 4.0\ipy.exe Now that I've had this idea, one might want to create other 2nd character codes after the Unix #! line... one could have #! Unix command processor #@ Windows command processor #$ OS/2 command processor #% Alternate Windows command processor. One could even port it to Unix: #!/usr/bin/#@launcher #@c:\python2.6\python.exe #^/usr/bin/python2.5 #/usr/bin/mono/IronPython2.6 for .NET 4.0/ipy.exe # I made up the line above, having no knowledge of Mono, but I think you get the idea Choice of command line would be an environment variable, I suppose, that the launcher would look at, or if none, then a system-specific default. It would have to search forward in the file until it finds the appropriate prefix or a line not starting with #, or starting with # or ##, at which point it would give up. ___ 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
On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote: On 3/8/2011 12:02 PM, Terry Reedy wrote: On 3/7/2011 9:31 PM, Reliable Domains wrote: The launcher need not be called python.exe, and maybe it would be better called #@launcher.exe (or similar, depending on its exact function details). I do not know that the '#@' part is about, but pygo would be short and expressive. If my proposal to make a line starting with #@ to be used instead of the Unix #! (#@ could be on the first or second line, to allow cross-platform scripts to use both, and Windows only scripts to not have #! You'd need to allow for it to be on the third line as well. pep-0263 has already taken the second line if it's in a script that has a Unix shebang. ), then #@launcher.exe (and # @launcherw.exe I suppose) would reflect the functionality of the launcher, which need not be tightly tied to Python, if it uses a separate line. But the launcher should probably not be the thing invoked from the command line, only implicitly when running scripts by naming them as the first thing on the command line. I'm of the opinion that attempting to parse a Unix #! line, and intuit what would be the equivalent on Windows is unnecessarily complex and error prone, and assumes that the variant systems are configured using the same guidelines (which the Python community may espouse, but may not be followed by all distributions, sysadmins, or users). I do not have a Windows system so I don't have a horse in this race but if the argument is to avoid complexity, be careful that your proposed solution isn't more complex than what you're avoiding. ie:: Now that I've had this idea, one might want to create other 2nd character codes after the Unix #! line... one could have #! Unix command processor #@ Windows command processor #$ OS/2 command processor #% Alternate Windows command processor. One could even port it to Unix: #!/usr/bin/#@launcher #@c:\python2.6\python.exe #^/usr/bin/python2.5 #/usr/bin/mono/IronPython2.6 for .NET 4.0/ipy.exe # I made up the line above, having no knowledge of Mono, but I think you get the idea Choice of command line would be an environment variable, I suppose, that the launcher would look at, or if none, then a system-specific default. It would have to search forward in the file until it finds the appropriate prefix or a line not starting with #, or starting with # or ##, at which point it would give up. -Toshio pgpkYA49vPaay.pgp Description: PGP signature ___ 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
On 3/8/2011 8:02 PM, Toshio Kuratomi wrote: On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote: On 3/8/2011 12:02 PM, Terry Reedy wrote: On 3/7/2011 9:31 PM, Reliable Domains wrote: The launcher need not be called python.exe, and maybe it would be better called #@launcher.exe (or similar, depending on its exact function details). I do not know that the '#@' part is about, but pygo would be short and expressive. If my proposal to make a line starting with #@ to be used instead of the Unix #! (#@ could be on the first or second line, to allow cross-platform scripts to use both, and Windows only scripts to not have #! You'd need to allow for it to be on the third line as well. pep-0263 has already taken the second line if it's in a script that has a Unix shebang. Thanks for your feedback Toshio... Indeed! I've been using Python 3 and UTF-8 encoding only long enough, I forgot about pep-0263, although I'd been aware of it before... Now I only port back to Python 2 for stuff I have to run on my web host, which runs Python 2.6, and those are all ASCII files by design. ), then #@launcher.exe (and # @launcherw.exe I suppose) would reflect the functionality of the launcher, which need not be tightly tied to Python, if it uses a separate line. But the launcher should probably not be the thing invoked from the command line, only implicitly when running scripts by naming them as the first thing on the command line. I'm of the opinion that attempting to parse a Unix #! line, and intuit what would be the equivalent on Windows is unnecessarily complex and error prone, and assumes that the variant systems are configured using the same guidelines (which the Python community may espouse, but may not be followed by all distributions, sysadmins, or users). I do not have a Windows system so I don't have a horse in this race but if the argument is to avoid complexity, be careful that your proposed solution isn't more complex than what you're avoiding. ie:: Yep, even after I wrote the below, I thought about not sending that part, for exactly that reason. But after slightly investigating the other Python implementations, I realized even more strongly that interpreting the Unix #! line is very limiting: 1) it requires the same version to exist on both Unix and Windows, which may often, but not always, be true. 2) it either hard-codes an alternative path name in the launcher, or hard-codes an algorithm to do lookups in the registry to find the alternative path names. Neither of these are very friendly to alternative Python implementations. 3) people concerned with keeping scripts and modules compatible with alternative implementations might have more than one implementation on their system. So the complexity I'm avoiding is the hard-coding sort of complexity. The complexity I propose adds flexibility that the hard-coding would be hard-pressed to achieve. Now that I've had this idea, one might want to create other 2nd character codes after the Unix #! line... one could have #! Unix command processor #@ Windows command processor #$ OS/2 command processor #% Alternate Windows command processor. One could even port it to Unix: #!/usr/bin/#@launcher #@c:\python2.6\python.exe #^/usr/bin/python2.5 #/usr/bin/mono/IronPython2.6 for .NET 4.0/ipy.exe # I made up the line above, having no knowledge of Mono, but I think you get the idea Choice of command line would be an environment variable, I suppose, that the launcher would look at, or if none, then a system-specific default. It would have to search forward in the file until it finds the appropriate prefix or a line not starting with #, or starting with # or ##, at which point it would give up. For PEP-0263 compliance, modify the terminator to be a line not starting with #, or a line starting with ##. This may cause reduced performance for scripts starting with large block comments without having the searched-for execution code... but only in the case where the searched-for execution code is not present. ___ 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
On 9/03/2011 1:43 PM, Glenn Linderman wrote: I'm of the opinion that attempting to parse a Unix #! line, and intuit what would be the equivalent on Windows is unnecessarily complex and error prone, and assumes that the variant systems are configured using the same guidelines (which the Python community may espouse, but may not be followed by all distributions, sysadmins, or users). That's why I propose a different line for Windows... it is as simple as the long-proven Unix #! line, but imposes no restrictions on or requirements that there be a #! line; it has more flexibility in that it could invoke different versions or provide different options on Unix and Windows if necessary for some environments. #!/usr/bin/env python2.6 -B #@c:\python26\python2.6.exe or #!/usr/bin/python2.5 #@C:\Program Files (x86)\IronPython 2.6 for .NET 4.0\ipy.exe I don't think that buys us much. A script with #!/usr/bin/env python could be distributed with an expectation it will work across various different machines (and possibly even different operating systems). A script with c:\... could not be distributed and expected to work reliably anywhere. ie, any script with a #! line (or even a #@ line) with a fully qualified Windows path can only be expected to work on a single machine - so there is no need to support both #! and #@ as the script is not even cross-machine portable, let alone cross-platform portable. The only way to expect a #! line to work across machines would be to have a virtual path - eg just python2.6 without any path specifier at all. In that case, I see no problem with reusing the #! from *nix systems and treating /usr/bin etc as a virtual specifier on Windows. If people find a need on Windows to add a fully-qualified path to this line (whatever the spelling), they are implicitly saying this script works only on the current machine. IOW, as soon as someone has: #!/usr/bin/env python2.6 -B #@c:\python26\python2.6.exe in their script, the script is targeted at exactly 1 specific machine, so why not just reuse the #! syntax? OTOH, if an existing script has: #!/usr/bin/env python2.6 -B They are attempting to declare in a portable way that Python 2.6 is necessary - so why force them to add a #@ line to make it work on Windows when the #! line is the only clue Windows needs to make it work automagically? Cheers, Mark ___ 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
On 3/8/2011 9:06 PM, Mark Hammond wrote: On 9/03/2011 1:43 PM, Glenn Linderman wrote: I'm of the opinion that attempting to parse a Unix #! line, and intuit what would be the equivalent on Windows is unnecessarily complex and error prone, and assumes that the variant systems are configured using the same guidelines (which the Python community may espouse, but may not be followed by all distributions, sysadmins, or users). That's why I propose a different line for Windows... it is as simple as the long-proven Unix #! line, but imposes no restrictions on or requirements that there be a #! line; it has more flexibility in that it could invoke different versions or provide different options on Unix and Windows if necessary for some environments. #!/usr/bin/env python2.6 -B #@c:\python26\python2.6.exe or #!/usr/bin/python2.5 #@C:\Program Files (x86)\IronPython 2.6 for .NET 4.0\ipy.exe I don't think that buys us much. A script with #!/usr/bin/env python could be distributed with an expectation it will work across various different machines (and possibly even different operating systems). A script with c:\... could not be distributed and expected to work reliably anywhere. ie, any script with a #! line (or even a #@ line) with a fully qualified Windows path can only be expected to work on a single machine - so there is no need to support both #! and #@ as the script is not even cross-machine portable, let alone cross-platform portable. Standard installation paths are accepted by about 99% of the users, so embedding standard installation paths can work well for that batch of users. Of course, Windows changes the standard path periodically, so that it different from versions prior to and including WinXP versus versions after WinXP. And they had no standard before WinNT (or if they did, few followed it). Your comment does point out a possible need for multiple standard installation paths just for different versions of Windows, though :( Also, corporate environments are generally quite standardized, so scripts developed within and for a corporation (or modified for use within a corporation) could quite successfully use such. You do make a good point, though, that Unix-based environments have more standardization in their diversity than Windows does. Back when I wrote Unix code, though, there were plenty of system utility programs that had different default paths on different Unix platforms. /usr/bin/env can cover some of that, but is also somewhat of a security hole. The only way to expect a #! line to work across machines would be to have a virtual path - eg just python2.6 without any path specifier at all. In that case, I see no problem with reusing the #! from *nix systems and treating /usr/bin etc as a virtual specifier on Windows. If people find a need on Windows to add a fully-qualified path to this line (whatever the spelling), they are implicitly saying this script works only on the current machine. IOW, as soon as someone has: #!/usr/bin/env python2.6 -B #@c:\python26\python2.6.exe in their script, the script is targeted at exactly 1 specific machine, so why not just reuse the #! syntax? OTOH, if an existing script has: #!/usr/bin/env python2.6 -B They are attempting to declare in a portable way that Python 2.6 is necessary - so why force them to add a #@ line to make it work on Windows when the #! line is the only clue Windows needs to make it work automagically? Your premise that using a standard installation path in #@ restricts the script to be targeted to one machine is fallacious, so the conclusions are also. You also missed the fact that the -B parameter was deemed necessary in the above for the Unix machine(s) of interest, but not needed for Windows, which a single line cannot impart (although that is an admittedly contrived example of potentially different option syntax). And the use of cpython on Unix and IronPython on Windows may be appropriate for some corporate environments. A lot of the Unix discussion mentioned things like curable by the sysadmin like in regards to the links... a sysadmin implies a corporate environment, and a locked-down path structure. Of course, /usr/bin/env is already a launcher type facility, specific to Unix, to mask variations between systems, and to overcome the fact that Unix itself will not walk the PATH to find a non-fully-qualified name. The #! line is clearly is NOT the only clue Windows needs to make it work automagically or we wouldn't be having this discussion at all. And it is not at all clear if a Windows machine contains Jython, IronPython, and Cython which one should be launched by a launcher. You could, of course, argue that python-dev is only concerned with CPython, and the launcher can be specific to CPython, and that argument might carry the day, but the CPython registry lookup necessary to make that happen doesn't help the users of alternate
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
On 9/03/2011 5:05 PM, Glenn Linderman wrote: Standard installation paths are accepted by about 99% of the users, so embedding standard installation paths can work well for that batch of users. Of course, Windows changes the standard path periodically, so that it different from versions prior to and including WinXP versus versions after WinXP. And they had no standard before WinNT (or if they did, few followed it). Your comment does point out a possible need for multiple standard installation paths just for different versions of Windows, though :( The python installer ignores Program Files - as much as anything I'm concerned about the drive letter - IIUC, Python will default to installing on the system drive, which may not be C: ... Your premise that using a standard installation path in #@ restricts the script to be targeted to one machine is fallacious, so the conclusions are also. Sorry - I should have said some machines with Python installed by the installer. Contrast this to the option of looking up the registry and you have all machines with Python installed by the installer. I'm not going to quibble about the percentages in the first category as I have no data to guide me, but I'm reasonably confident about the all in the second. ... The #! line is clearly is NOT the only clue Windows needs to make it work automagically or we wouldn't be having this discussion at all. Sorry - I should have been clear - I meant the only clue a windows specific Python launcher needs. And it is not at all clear if a Windows machine contains Jython, IronPython, and Cython which one should be launched by a launcher. I think it is reasonably clear: it would be the same version which would be launched on most *nix systems. Are there any systems where /usr/bin/python would use Jython, for example? You could, of course, argue that python-dev is only concerned with CPython, and the launcher can be specific to CPython, and that argument might carry the day, but the CPython registry lookup necessary to make that happen doesn't help the users of alternate implementations a bit, forcing each of them to implement their own launcher as well... I'd have no problem with the Windows launcher supporting other implementations - I expect something like /usr/bin/jython would be reasonable. How we locate the installed jython is indeed an interesting problem, but I'd guess it is surmountable - especially if we can get the buy-in of these alternate implementations for their future releases. #!/usr/bin/env python2.6 #@C:\Program Files\Env.exe ipy2.6.3.exe As above, the C: assumes Windows is installed on C: - that may be common, but not universal. Further, a 64bit machine would probably want \Program Files (x86) (which is becoming more and more common) in .py files and #!/usr/bin/env python2.6 #@C:\Program Files\Env.exe ipy2.6.3w.exe in .pyw files. I'm slightly skeptical about that - .pyw files are surely rare on *nix systems and as we've discussed, pyw files are generally not meant to be cmd-line scripts. IOW, I'm skeptical scripts exist which are meant to work with '/usr/bin/env python2.6' on *nix and pythonw.exe on windows. ... So no matter what is done, it won't solve world hunger. Probably that's why Windows users have been left high and dry for years in this regard... there is no system Python on it, out of the box, so the only users are those that are smart enough to download and install and configure things, and those who use a Python embedded into an application, at the cost of a Python installation per application, because there has been no system Python, and because Windows users are not perceived to be capable of, or willing to bother with, downloading and installing various requisite dependencies. The resulting vacuum has been filled by people with different points of view, because there has been no technique implemented, none declared to be best, and anarchy and variant workarounds have abounded. I'm glad solving world hunger is out of scope for this :) I understand your position but my personal opinion is that simple support for #! is more desirable. I'd be happy to go with the consensus though... Cheers, Mark ___ 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
On 3/8/2011 10:27 PM, Mark Hammond wrote: On 9/03/2011 5:05 PM, Glenn Linderman wrote: Standard installation paths are accepted by about 99% of the users, so embedding standard installation paths can work well for that batch of users. Of course, Windows changes the standard path periodically, so that it different from versions prior to and including WinXP versus versions after WinXP. And they had no standard before WinNT (or if they did, few followed it). Your comment does point out a possible need for multiple standard installation paths just for different versions of Windows, though :( The python installer ignores Program Files - as much as anything I'm concerned about the drive letter - IIUC, Python will default to installing on the system drive, which may not be C: The system drive usually is C:, there is a fair bit of software that won't work when it is not C:, and in any particular corporate environment it is usually standardized by the IT folks. And you are referring specifically to the CPython installer as the IronPython (for example) does install in Program Files. ... Your premise that using a standard installation path in #@ restricts the script to be targeted to one machine is fallacious, so the conclusions are also. Sorry - I should have said some machines with Python installed by the installer. Contrast this to the option of looking up the registry and you have all machines with Python installed by the installer. I'm not going to quibble about the percentages in the first category as I have no data to guide me, but I'm reasonably confident about the all in the second. ... The #! line is clearly is NOT the only clue Windows needs to make it work automagically or we wouldn't be having this discussion at all. Sorry - I should have been clear - I meant the only clue a windows specific Python launcher needs. Sorrier yet :) I think you really meant the only clue a Windows specific CPython specific Python launcher needs. And it is not at all clear if a Windows machine contains Jython, IronPython, and Cython which one should be launched by a launcher. I think it is reasonably clear: it would be the same version which would be launched on most *nix systems. Are there any systems where /usr/bin/python would use Jython, for example? I have no idea the answer to your question... I don't think you do either. There may be some. The sysadmin can change what /usr/bin/python points to. I have seen plenty of Unix systems where /bin/sh is really bash, for example, so if the replacement is compatible enough the sysadmin may choose to make such a change. You could, of course, argue that python-dev is only concerned with CPython, and the launcher can be specific to CPython, and that argument might carry the day, but the CPython registry lookup necessary to make that happen doesn't help the users of alternate implementations a bit, forcing each of them to implement their own launcher as well... I'd have no problem with the Windows launcher supporting other implementations - I expect something like /usr/bin/jython would be reasonable. How we locate the installed jython is indeed an interesting problem, but I'd guess it is surmountable - especially if we can get the buy-in of these alternate implementations for their future releases. Indeed. But now you have a script that require jython on all machines that it runs on, rather than being flexible in being configurable to use the preferred implementations of a particular environment (perhaps CPython 2.6 on Unix boxes, and Jython 2.5 on Windows boxes, or vice versa). #!/usr/bin/env python2.6 #@C:\Program Files\Env.exe ipy2.6.3.exe As above, the C: assumes Windows is installed on C: - that may be common, but not universal. Further, a 64bit machine would probably want \Program Files (x86) (which is becoming more and more common) Yes, same C: issue as above, see response above. And if the launcher comes in a 64-bit version for 64-bit machines, then it would be installed as C:\Program Files\Env.exe on the 64-bit machines. That should be straightforward to achieve. in .py files and #!/usr/bin/env python2.6 #@C:\Program Files\Env.exe ipy2.6.3w.exe in .pyw files. I'm slightly skeptical about that - .pyw files are surely rare on *nix systems and as we've discussed, pyw files are generally not meant to be cmd-line scripts. IOW, I'm skeptical scripts exist which are meant to work with '/usr/bin/env python2.6' on *nix and pythonw.exe on windows. Indeed, .pyw files are even rare on my Windows box :) A GUI sort of Python script would generally want to be .pyw on a Windows box. There are a variety of cross-platform GUIs such as Qt and wxWindows, so those same scripts could be written to work on Unix boxes also. Unix, happily, doesn't care about the name of the script as long as the #! line points the right place, and neither does CPython on Unix, at least for
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
On 7 March 2011 01:18, Mark Hammond skippy.hamm...@gmail.com wrote: That said though, I'm only -0 on python2.exe/python3.exe - I don't think it will hurt, but also don't think it will help that much in practice. It may also turn out to be unnecessary should a complete solution be implemented - eg, a python launcher which (a) read the shebang lines and (b) allowed something like python -3 on the command-line would render both python3.exe and requests to have multiple installed Python versions on the PATH redundant. That sounds like a fairly cool idea. So if I follow what you're suggesting, we'd have a single python.exe, probably installed in system32, which did the necessary command line juggling and shebang parsing, then simply redirected to the appropriate Python interpreter? Presumably that launcher would be pretty version independent, so (a) the one that gets installed with Python 3.3 would support older versions even though they didn't include the launcher themselves, (b) overwriting the launcher when a new version of Python is installed wouldn't be too big a deal, and (c) it could be released as a standalone package for people with only older versions of Python installed? I like this idea. If I had the spare time (I don't :-() I'd work on this myself. +1 from me. Paul. ___ 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
On 7/03/2011 9:33 PM, Paul Moore wrote: That sounds like a fairly cool idea. So if I follow what you're suggesting, we'd have a single python.exe, probably installed in system32, which did the necessary command line juggling and shebang parsing, then simply redirected to the appropriate Python interpreter? Presumably that launcher would be pretty version independent, so (a) the one that gets installed with Python 3.3 would support older versions even though they didn't include the launcher themselves, (b) overwriting the launcher when a new version of Python is installed wouldn't be too big a deal, and (c) it could be released as a standalone package for people with only older versions of Python installed? Yup - although I think a pythonw.exe launcher would be needed too (for the same reasons we need python.exe and pythonw.exe today) I like this idea. If I had the spare time (I don't :-() I'd work on this myself. +1 from me. Cool - I may have a go at this over the next few weekends... :) Cheers, Mark ___ 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
On 07/03/2011 10:49, Mark Hammond wrote: On 7/03/2011 9:33 PM, Paul Moore wrote: That sounds like a fairly cool idea. So if I follow what you're suggesting, we'd have a single python.exe, probably installed in system32, which did the necessary command line juggling and shebang parsing, then simply redirected to the appropriate Python interpreter? Presumably that launcher would be pretty version independent, so (a) the one that gets installed with Python 3.3 would support older versions even though they didn't include the launcher themselves, (b) overwriting the launcher when a new version of Python is installed wouldn't be too big a deal, and (c) it could be released as a standalone package for people with only older versions of Python installed? Yup - although I think a pythonw.exe launcher would be needed too (for the same reasons we need python.exe and pythonw.exe today) I like this idea. If I had the spare time (I don't :-() I'd work on this myself. +1 from me. Agreed all round. In the highly unlikely event that I find some time I too might have a play with the idea. The devil will undoubtedly be in the details. I've implemented a Pure-python version of this before, but found it unacceptably slow for anything but ad-hoc use. Still, it was useful for that :) TJG ___ 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
On Sunday, March 6, 2011 at 9:53 AM, Brian Curtin wrote: On Sun, Mar 6, 2011 at 11:41, Michael Foord fuzzy...@voidspace.org.uk wrote: - Hide quoted message - I would like to see us create version specific (i.e. python32.exe / python32w.exe) binaries (or links if we drop support for earlier versions of Windows or some filesystems - I'm agnostic on that issue) *plus* a python3.exe / python3w.exe with last install wins (as it is for currently for file associations). I don't have an ActiveState install on this machine, but I know they have been adding some form of version specific binaries for a while, so maybe they can comment on what they chose and how they chose it, and how people are using it. Are Sridhar or Trent on here? ActivePython for Windows includes the following binaries on Windows: * python.exe * python3.2.exe * python3.xe (plus the `pythonw` versions) python3.2.exe is better than python32.exe because that matches the invocation (eg: python3.2 -m foo) on Unix. Similarly for 2.x (python2.exe / python2.7.exe). All of this is particularly useful if the installer adds Python directory to %PATH% (which is the case for ActivePython, but not the one from python.org). -srid ___ 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
Tim Golden wrote: On 07/03/2011 10:49, Mark Hammond wrote: On 7/03/2011 9:33 PM, Paul Moore wrote: That sounds like a fairly cool idea. So if I follow what you're suggesting, we'd have a single python.exe, probably installed in system32, which did the necessary command line juggling and shebang parsing, then simply redirected to the appropriate Python interpreter? Presumably that launcher would be pretty version independent, so (a) the one that gets installed with Python 3.3 would support older versions even though they didn't include the launcher themselves, (b) overwriting the launcher when a new version of Python is installed wouldn't be too big a deal, and (c) it could be released as a standalone package for people with only older versions of Python installed? Yup - although I think a pythonw.exe launcher would be needed too (for the same reasons we need python.exe and pythonw.exe today) I like this idea. If I had the spare time (I don't :-() I'd work on this myself. +1 from me. Agreed all round. +1 here also. This seems a sensible solution to the 'Windows Problem'. ;) ~Ethan~ ___ 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
On 07/03/2011 05:19, Mark Hammond wrote: [snip...] (B) declare the Python version in the content of the script file. This cures most of the ripple effects of the above, but requires a launcher or wrapper program to be designed, implemented, and installed. There are a variety of subsolutions for different ways of declaring the version. snip a few options Without putting too much thought into it, I think a simple scheme could work where the path must either be /usr/bin/python[23]? or a fully-qualified path to a Python executable. IIUC, this should allow most scripts to have a shebang line that does the right thing on *nix and Windows systems while still offering maximum flexibility on Windows. /usr/bin/env python is popular too, and it would be nice to support the new aliases (or binaries) being created by the pep (python2 / python3). Michael By default, for Python, the wrapper would get associated only with .py files. There would probably also need to be the same for .pyw, but it would be almost identical to the .py handling. Cheers, Mark ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On 07/03/2011 17:21, Sridhar Ratnakumar wrote: On Sunday, March 6, 2011 at 9:53 AM, Brian Curtin wrote: On Sun, Mar 6, 2011 at 11:41, Michael Foordfuzzy...@voidspace.org.uk mailto:fuzzy...@voidspace.org.ukwrote: - Hide quoted message - I would like to see us create version specific (i.e. python32.exe / python32w.exe) binaries (or links if we drop support for earlier versions of Windows or some filesystems - I'm agnostic on that issue) *plus* a python3.exe / python3w.exe with last install wins (as it is for currently for file associations). I don't have an ActiveState install on this machine, but I know they have been adding some form of version specific binaries for a while, so maybe they can comment on what they chose and how they chose it, and how people are using it. Are Sridhar or Trent on here? ActivePython for Windows includes the following binaries on Windows: * python.exe * python3.2.exe * python3.xe (plus the `pythonw` versions) python3.2.exe is better than python32.exe because that matches the invocation (eg: python3.2 -m foo) on Unix. Similarly for 2.x (python2.exe / python2.7.exe). All of this is particularly useful if the installer adds Python directory to %PATH% (which is the case for ActivePython, but not the one from python.org). Sounds ideal. :-) Michael -srid -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On 07/03/2011 01:18, Mark Hammond wrote: [snip...] That said though, I'm only -0 on python2.exe/python3.exe - I don't think it will hurt, but also don't think it will help that much in practice. It may also turn out to be unnecessary should a complete solution be implemented - eg, a python launcher which (a) read the shebang lines and (b) allowed something like python -3 on the command-line would render both python3.exe and requests to have multiple installed Python versions on the PATH redundant. A python launcher as you describe is a *great* idea. A few concerns: * we're missing an opportunity to do something easy (Martin is happy to modify the installer and says it is easy) for something that may or may not happen * will you call it python.exe? will it be installed by the python installer? - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if not then python foo.py on the command line will *still* not work... - it will still have to be installed on the PATH, but I guess System32 will do for that - users without admin rights will still have to modify their PATH manually and place it somewhere else * we're (yet again) making instructions for running stuff on Windows *different* to other platforms (and making tutorials written for other pythons not work in certain ways) * as I work with multiple platforms it would be really nice if the same invocations worked across all of them - whilst I say again that I really like the idea of the launcher it doesn't conflict with the other suggestions (creating multiple binaries) and as you (Mark) say it wouldn't hurt... So why not do both? We could create the extra binaries to bring Python on Windows inline with the unix conventions for command line invocations, and the new launcher can follow on as a nice addition. Note that the discussions about the Python installer adding to the PATH won't be *ended* by the creation of the installer. A typical install on a Unix-like system adds various other utilities to the path that merely adding the top-level of your Python install on Windows still doesn't add. In particular distutils installed scripts go into a subdirectory of your Python install. All the best, Michael Foord Cheers, Mark -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On 7 March 2011 20:33, Michael Foord fuzzy...@voidspace.org.uk wrote: So why not do both? We could create the extra binaries to bring Python on Windows inline with the unix conventions for command line invocations, and the new launcher can follow on as a nice addition. I was assuming that the exes in the installation directories would include version-specific ones (bringing Windows in line with Unix behaviour) and the python.exe launcher would be in system32 (making python foo.py work on the command line) and would redirect to the default python for the box (or a specific one, if -2, -3, -2.7 or whatever flags were specified). The launcher could also (as per Mark's suggestion) interpret a shebang line in the script, so that scripts could specify their required version without needing a different command,or multiple version-specific extensions. So yes, let's do both. That's certainly what I expected. Paul. ___ 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
On Mar 7, 2011, at 3:49 PM, Paul Moore wrote: The launcher could also (as per Mark's suggestion) interpret a shebang line in the script, so that scripts could specify their required version without needing a different command,or multiple version-specific extensions. Note that, on Unix, python file.py doesn't choose the correct version of python to run by looking at a shebang, it just runs the version of python installed as python. Only ./file.py looks at the shebang (assuming that file is marked executable). Is the proposal to make python.exe do that on windows? That is a rather significant difference from the unix behavior. ___ 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
On 07/03/2011 22:18, James Y Knight wrote: On Mar 7, 2011, at 3:49 PM, Paul Moore wrote: The launcher could also (as per Mark's suggestion) interpret a shebang line in the script, so that scripts could specify their required version without needing a different command,or multiple version-specific extensions. Note that, on Unix, python file.py doesn't choose the correct version of python to run by looking at a shebang, it just runs the version of python installed as python. Only ./file.py looks at the shebang (assuming that file is marked executable). Is the proposal to make python.exe do that on windows? That is a rather significant difference from the unix behavior. By default python.exe is not on the path in windows, so unless the current directory is the python install (or you have manually changed your path) python foo.py does *nothing*. That is a *very* big difference from unix behaviour. The proposal is (apparently) to create another executable called python.exe that is put on the path by the installer (if the user has the right permissions to do this). I believe the intention is that python foo.py *will* then lookup the shebang to run the right version of python, defaulting to the last installed version of python (I assume). All the best, Michael Foord ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On 8/03/2011 7:33 AM, Michael Foord wrote: A python launcher as you describe is a *great* idea. A few concerns: * we're missing an opportunity to do something easy (Martin is happy to modify the installer and says it is easy) for something that may or may not happen Don't let my -0 stop anyone :) * will you call it python.exe? will it be installed by the python installer? - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if not then python foo.py on the command line will *still* not work... Calling it python.exe would make the most sense for people who don't look behind the curtain, but I agree it could potentially be confusing for people. Further, we would need to ensure we didn't create an infinite loop where the launcher python.exe found a python.exe it thought was an appropriate sub-process, but where it turns out it is actually another launcher. Having it installed by the Python installer also makes sense to me but I'd be very interested in Martin's take on this (and also on everything else we are discussing here). * we're (yet again) making instructions for running stuff on Windows *different* to other platforms (and making tutorials written for other pythons not work in certain ways) Actually, I'd argue we are making them more similar as we would be honoring a shebang line and allowing the exact same mechanism be used to denote the major version of Python needed. * as I work with multiple platforms it would be really nice if the same invocations worked across all of them - whilst I say again that I really like the idea of the launcher it doesn't conflict with the other suggestions (creating multiple binaries) and as you (Mark) say it wouldn't hurt... So why not do both? We could create the extra binaries to bring Python on Windows inline with the unix conventions for command line invocations, and the new launcher can follow on as a nice addition. Note that the discussions about the Python installer adding to the PATH won't be *ended* by the creation of the installer. A typical install on a Unix-like system adds various other utilities to the path that merely adding the top-level of your Python install on Windows still doesn't add. In particular distutils installed scripts go into a subdirectory of your Python install. The distutils scripts are a good point. To be honest, apart from the file association issue, I can't see much advantage in doing both - if all Python directories end up on your path such that python3 foo.py magically works, then the launcher script is adding complexity without bringing much to the table. Further, I'm somewhat skeptical that the file associations are used by that many people in the real world - currently when you double-click on a script you get a temp console created, and should a traceback be raised, you get to see it for about 2ms before the console is destroyed. Some people may be .pyw to avoid that, but then their script has to go to extraordinary lengths to display such errors in a UI of some kind. I suspect most people just find it more convenient to launch such scripts from a console. Maybe a quick poll on python-list would be reasonable... Cheers, Mark ___ 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
On 07/03/2011 22:48, Mark Hammond wrote: On 8/03/2011 7:33 AM, Michael Foord wrote: A python launcher as you describe is a *great* idea. A few concerns: * we're missing an opportunity to do something easy (Martin is happy to modify the installer and says it is easy) for something that may or may not happen Don't let my -0 stop anyone :) Will you be at PyCon this year? * will you call it python.exe? will it be installed by the python installer? - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if not then python foo.py on the command line will *still* not work... Calling it python.exe would make the most sense for people who don't look behind the curtain, but I agree it could potentially be confusing for people. Further, we would need to ensure we didn't create an infinite loop where the launcher python.exe found a python.exe it thought was an appropriate sub-process, but where it turns out it is actually another launcher. Sounds like fun. :-) Having it installed by the Python installer also makes sense to me but I'd be very interested in Martin's take on this (and also on everything else we are discussing here). Ditto. * we're (yet again) making instructions for running stuff on Windows *different* to other platforms (and making tutorials written for other pythons not work in certain ways) Actually, I'd argue we are making them more similar as we would be honoring a shebang line and allowing the exact same mechanism be used to denote the major version of Python needed. Well, except (as pointed out a few minutes ago) that *isn't* what unix does (python foo.py does not honour the shebang). It gets us to something that works reliably though so I still like the idea. * as I work with multiple platforms it would be really nice if the same invocations worked across all of them - whilst I say again that I really like the idea of the launcher it doesn't conflict with the other suggestions (creating multiple binaries) and as you (Mark) say it wouldn't hurt... So why not do both? We could create the extra binaries to bring Python on Windows inline with the unix conventions for command line invocations, and the new launcher can follow on as a nice addition. Note that the discussions about the Python installer adding to the PATH won't be *ended* by the creation of the installer. A typical install on a Unix-like system adds various other utilities to the path that merely adding the top-level of your Python install on Windows still doesn't add. In particular distutils installed scripts go into a subdirectory of your Python install. The distutils scripts are a good point. To be honest, apart from the file association issue, I can't see much advantage in doing both - if all Python directories end up on your path such that python3 foo.py magically works, then the launcher script is adding complexity without bringing much to the table. Further, I'm somewhat skeptical that the file associations are used by that many people in the real world - currently when you double-click on a script you get a temp console created, and should a traceback be raised, you get to see it for about 2ms before the console is destroyed. Some people may be .pyw to avoid that, but then their script has to go to extraordinary lengths to display such errors in a UI of some kind. I suspect most people just find it more convenient to launch such scripts from a console. Maybe a quick poll on python-list would be reasonable... The launcher program could thrive without *having* to be part of a standard Python install. Offering it separately makes sense even if it *is* included. If we do both then users can vote with their feet. Personally I suspect that many people, particularly new programmers, will appreciate the launcher but more advanced developers will want more precise control (and similarity to unix for command line invocations). I agree with you about file associations. They are useful for .pyw programs (like IDLE), but not for scripts. All the best, Michael Cheers, Mark -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
Mark Hammond wrote: Yup - although I think a pythonw.exe launcher would be needed too Couldn't the launcher look at the extension of the file being launched to decide about this? -- Greg ___ 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
Michael Foord wrote: - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if not then python foo.py on the command line will *still* not work... However, if it's installed as the exe associated with the .py and .pyw extensions, then simply 'foo.py' on the command line *will* work, and will work better than it does now. -- Greg ___ 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
On 07/03/2011 23:52, Greg Ewing wrote: Michael Foord wrote: - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if not then python foo.py on the command line will *still* not work... However, if it's installed as the exe associated with the .py and .pyw extensions, then simply 'foo.py' on the command line *will* work, and will work better than it does now. So long as '.py' and '.pyw' are set in the PATHEXT environment variable. (Which again the Python installer doesn't do by default.) Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On 8/03/2011 10:15 AM, Greg Ewing wrote: Mark Hammond wrote: Yup - although I think a pythonw.exe launcher would be needed too Couldn't the launcher look at the extension of the file being launched to decide about this? Nope - the launcher itself must be marked as console or windows, and hence would suffer the exact same problem which needs us to have python.exe and pythonw.exe in the first place (ie, in some cases you get a temp console where you don't want one, and in other cases you get a new console where you wanted an existing one to be used) Mark ___ 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
On 3/7/2011 4:00 PM, Michael Foord wrote: On 07/03/2011 23:52, Greg Ewing wrote: Michael Foord wrote: - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if not then python foo.py on the command line will *still* not work... However, if it's installed as the exe associated with the .py and .pyw extensions, then simply 'foo.py' on the command line *will* work, and will work better than it does now. So long as '.py' and '.pyw' are set in the PATHEXT environment variable. (Which again the Python installer doesn't do by default.) No, PATHEXT only means you can invoke foo.py and foo and get the same results (sometimes, depending on what all in on PATH and PATHEXT) ___ 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
On 3/7/2011 2:18 PM, James Y Knight wrote: On Mar 7, 2011, at 3:49 PM, Paul Moore wrote: The launcher could also (as per Mark's suggestion) interpret a shebang line in the script, so that scripts could specify their required version without needing a different command,or multiple version-specific extensions. Note that, on Unix, python file.py doesn't choose the correct version of python to run by looking at a shebang, it just runs the version of python installed as python. Only ./file.py looks at the shebang (assuming that file is marked executable). Is the proposal to make python.exe do that on windows? That is a rather significant difference from the unix behavior. The launcher need not be called python.exe, and maybe it would be better called #@launcher.exe (or similar, depending on its exact function details). For launching from the command line, if various versions python binaries or batch files are on the PATH, then appropriate explicit python invocation python foo.py # Just like Unix python2 foo.py python3 foo.py should launch the specified version (where python may be somewhat ambiguous) but foo.py # with the help of a launcher this could be just like Unix too would implicitly use the launcher, as would launching it from the GUI. There are two problems here, explicit command-line invocation, and GUI/assoc invocation. A launcher need not, and probably should not, do anything for explicit python invocation, but would only solve the implicit and GUI type of invocations. ___ 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
On Sat, Mar 5, 2011 at 9:33 PM, Mark Hammond skippy.hamm...@gmail.com wrote: IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate python2.bat and python3.bat files and put them in System32 with a last installed wins policy. The fact this doesn't help users installing Python just for me is fine too from the POV of matching *nix systems - a user installing a private Python build on *nix also doesn't get the python2 and python3 conveniences, nor the automatic PATH convenience. But in practice I expect this would *not* be OK - which just highlights the risks of trying to generalize a specific observed problem on one OS to others. Why not modify the windows installers to install into C:\Python\X.Y and have the .bat files generated in C:\Python which is what I have been doing manually since py25. I just add C:\Python to the system Path then create/modify the bat files for new versions of python I install. C:\Python\python.bat - 3.2/python.exe C:\Python\python2.bat - 2.7/python.exe C:\Python\python3.bat - 3.2/python.exe C:\Python\python2.5.bat - 2.5/python.exe ... Something I have been thinking about recently though is outside the scope of the pep is writing a python.exe, to replace the python.bat, that would try to read the shebang line of the file to send it to the right version of python. Then I just associate py files with the dispatcher exe and everything should work as intended. ___ 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
On 6/03/2011 11:51 PM, Dj Gilcrease wrote: Why not modify the windows installers to install into C:\Python\X.Y and have the .bat files generated in C:\Python which is what I have been doing manually since py25. I just add C:\Python to the system Path then create/modify the bat files for new versions of python I install. That sounds like a reasonable scheme people may choose to use - however, it doesn't really address the basic issue - something still needs to add c:\Python to PATH, and the scheme itself doesn't really necessitate the common parent directory - ie, it is fundamentally the same (if less clean) as the existing c:\pythonx with a (eg) c:\python-cmd or c:\python-scripts directory with the .bat files - especially given the various installations can be located via the registry. ... Something I have been thinking about recently though is outside the scope of the pep is writing a python.exe, to replace the python.bat, that would try to read the shebang line of the file to send it to the right version of python. Then I just associate py files with the dispatcher exe and everything should work as intended. But where would such a python.exe live and how would that directory end up on the PATH? On the more general idea though, it could have legs as it would solve the file association issue for files which include the shebang and arrange for the status-quo (or better) for files which don't... But this sounds like a different PEP ;) Cheers, Mark. ___ 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
On Sun, Mar 6, 2011 at 8:10 AM, Mark Hammond mhamm...@skippinet.com.au wrote: That sounds like a reasonable scheme people may choose to use - however, it doesn't really address the basic issue - something still needs to add c:\Python to PATH, and the scheme itself doesn't really necessitate the common parent directory - ie, it is fundamentally the same (if less clean) as the existing c:\pythonx with a (eg) c:\python-cmd or c:\python-scripts directory with the .bat files - especially given the various installations can be located via the registry. True, and since System32 is already on the path, having the installer generate the bat files there is probably the best solution for this pep. ___ 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
On 6 March 2011 02:33, Mark Hammond skippy.hamm...@gmail.com wrote: IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate python2.bat and python3.bat files and put them in System32 with a last installed wins policy. No, no, no! Please no! Bat files are a lousy way of writing wrappers on Windows, as they don't nest. I've lost count of the number of times I've been tripped up by putting a series of commands into a batch file, only to have them fail because somewhere in the middle is a bat file wrapper which makes the outer bat file stop part way through :-( /rant Paul. ___ 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
Using batch files is a poor idea, IMO, because you have to explicitly call a batch file from another, or the remainder of the caller will not execute. Installing to System32 s also questionable, but if it's just the launchers, it might be okay. From an installer's perspective, it would really help if those files kept consistent component GUIDs and had a Windows version block so it could upgrade consistently if it changes in the future I think Glenn Linderman hit the use cases on the head; I'm unclear why he was against the overhead of a helper executable. The things I would really want solutions for are these: * double click on a script, and have it launch the right python (2 or 3, w or not) * Probably scan for the final python[.\d]+ string and assume it's relevant. * be able to easily invoke python to interpret a script from the command prompt I'd be comfortable with setting associations to a set of thin executable wrappers which examined the #! line to extract a python version. It could fall back to the default version of python, which could be defined as the highest installed on the machine, or could be customizable by the machine's administrator. If this wrapper script passes on all command line parameters, it could also be a reasonable way to invoke python from the command line. Is there a good way for the wrapper to know what versions of python are available on Windows? Moving forward we could have a pythonx.y installer set a value in a known registry key, and document how to register an older python with this key. The default value of the key could be the mechanism for setting a default python version. I'm willing to clarify this and/or look into providing patches if it would help; the only potentially sticky point is the contribution agreement, but I wouldn't expect trouble with my employer. Michael ___ 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
On Sun, Mar 6, 2011 at 09:07, Michael Urman mur...@gmail.com wrote: I think Glenn Linderman hit the use cases on the head; I'm unclear why he was against the overhead of a helper executable. Interpreter startup time is increasing with every version IIRC**, so adding another slowdown means we have to step very carefully in this area. I'm +1 for much of the usability side of things, but we must remain mindful of performance. ** I've run some numbers but they're at work, so I'll have to grab them tomorrow. ___ 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
On 06/03/2011 02:33, Mark Hammond wrote: On 6/03/2011 12:37 AM, Michael Foord wrote: On 05/03/2011 07:02, Nick Coghlan wrote: On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammondmhamm...@skippinet.com.au wrote: I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the last installed wins issue Martin mentions - only all of them taken together will fix this issue - not that I personally consider it particularly broken - more like sub-optimal :) I updated the draft PEP, explicitly bringing Mac OS X and Cygwin within the scope of the recommendation, and excluding PYTHON* environment variable considerations and Windows-related proposals. The Windows section does include a hit-list that may serve as a useful starting point if someone else felt like starting a Windows specific PEP, though. The issues are relevant to Windows (there are *other* issues as well but that doesn't mean that the same issue doesn't apply). Guido also said he would like to see Windows addressed. What issues specifically? If I look at the current PEP language, it refers to the default version of the Python interpreter and all new code that needs to invoke the Python interpreter. Neither of these apply in any meaningful way to Windows. People often invoke the Python interpreter from the command line to run code on Windows. It could be argued that the latter could include .bat files which use Python but that sounds like a theoretical problem (ie, I haven't heard much noise about that) where PEP394 is addressing an observed practical problem. I have my Python installs on my PATH (as do most Windows developers I know) and absent batch files I create myself I have no way of distinguishing between Python 2 and Python 3 (or other versions) because the Windows installer only creates python.exe. On Windows it seems to be just about 'python2' and 'python3' doing the correct thing in a default command prompt, which while desirable ignores the broader issues (eg, the file associations and anything else windowsy and not driven by the command-prompt) I'm glad it is desirable. Yes there are other issues, yes they should be addressed, but not as part of this PEP. I'll be happy to try and come to some consensus with Martin (and others) on what we *can* do for Windows (as similar to the other platforms as possible would be my goal) and provide appropriate text for the PEP. IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate python2.bat and python3.bat files and put them in System32 with a last installed wins policy. The fact this doesn't help users installing Python just for me is fine too from the POV of matching *nix systems - a user installing a private Python build on *nix also doesn't get the python2 and python3 conveniences, nor the automatic PATH convenience. But in practice I expect this would *not* be OK - which just highlights the risks of trying to generalize a specific observed problem on one OS to others. bat files are far from ideal for the reasons that others have expressed. I would like to see us create version specific (i.e. python32.exe / python32w.exe) binaries (or links if we drop support for earlier versions of Windows or some filesystems - I'm agnostic on that issue) *plus* a python3.exe / python3w.exe with last install wins (as it is for currently for file associations). Whether we make those automatically available by installing into System32 or do that later by allowing the installer (optionally) to add a PATH entry I don't mind. Martin seems not to mind this idea and Paul Moore is +1 and Guido would like Windows at least addressed by the PEP, so I would *like* this added to the PEP unless there is substantial opposition to us doing this. All the best, Michael Foord Cheers, Mark -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On Sun, Mar 6, 2011 at 11:41, Michael Foord fuzzy...@voidspace.org.ukwrote: I would like to see us create version specific (i.e. python32.exe / python32w.exe) binaries (or links if we drop support for earlier versions of Windows or some filesystems - I'm agnostic on that issue) *plus* a python3.exe / python3w.exe with last install wins (as it is for currently for file associations). I don't have an ActiveState install on this machine, but I know they have been adding some form of version specific binaries for a while, so maybe they can comment on what they chose and how they chose it, and how people are using it. Are Sridhar or Trent on here? (sorry if this was already mentioned -- I joined late and only skimmed many of the posts) ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
Am 06.03.2011 21:12, schrieb Kerrick Staley: Some nitpicks: 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. Regards, Martin ___ 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
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 m...@kerrickstaley.com, @@ -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
I should've mentioned that I'd like a consensus (or a lack of protest) on the changes related to these snippets: [...] -Exclusions of MS Windows I think you won't get consensus on that: there are strong proponents and strong opponents (I think Mark being a strong proponent of such exclusion, and Michael being a strong opponent). I personally don't care either way much, but will only do with the Windows installer what the PEP tells me to do (if anything) (more precisely, I remain -0 on changing 2.7, and +0 on changing 3.3). So it comes back to you as the PEP author to take a stance, which you did. It's recommended tradition to record any opposing opinions in the PEP, along with rebuttals, so that the same arguments aren't brought up over and over again. If discussion then settles, it's up to the PEP dictator to approve or reject the whole text. Regards, Martin ___ 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
In article AANLkTimPEDWCsiOXfq=ppyypfkbmr-oja54m-cnaq...@mail.gmail.com, Kerrick Staley m...@kerrickstaley.com wrote: 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 FYI - I will have some comments on the PEP, primarily with regard to OS X, in the next day. -- Ned Deily, n...@acm.org ___ 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
On 06/03/2011 21:36, Martin v. Löwis wrote: I should've mentioned that I'd like a consensus (or a lack of protest) on the changes related to these snippets: [...] -Exclusions of MS Windows I think you won't get consensus on that: there are strong proponents and strong opponents (I think Mark being a strong proponent of such exclusion, and Michael being a strong opponent). Guido said he would like to see the PEP address Windows, although that requires *some* consensus. Paul Moore was +1 on Windows being included. Mark did accept that some of the changes were desirable, but was also concerned they didn't address all the issues on Windows. I *would* like to see all the issues addressed but I think that is outside the scope of this PEP. The solution I would like to see for Windows, with other issues to be addressed as issues in the bug tracker: Create version specific (i.e. python32.exe / python32w.exe) binaries *plus* a python3.exe / python3w.exe in the installer. Similar for Python 2.7 if we decide to modify 2.7 for the other platforms. (Presumably the same also applies to 3.1?) It would be fine for these to be binaries duplicating python.exe, or to be links (which will mean not supporting some filesystems and possibly not some versions of python). This means that Windows users who add their Python install to the path will have python, python3 and python3.2 on the path. (I believe this means *most* Windows developers.) Which binary python and python3 actually launch when invoked from the command line will depend which comes first in the path. If the installer is enhanced to (optionally) automatically add a python install to the path then this should follow the last installed wins rules as file associations do currently. An alternative solution, (perfectly acceptable to me) is that when python is installed on Windows for all users it could put python.exe *plus* the aforementioned version specific binaries into System32 which would automatically put them on the path. This also has the last installed wins behaviour for python.exe and python3.exe. (Would it require installing the appropriate msvcrt into System32 as well and is this desirable?) A generic Python launcher that could be used for the file association and honours the Unix style shebang line, delegating to the appropriate version of python, is an interesting idea but out of the scope of this PEP. It would be interesting to see if Mark, or others, are strongly opposed to these ideas or have strong preferences. If the biggest downside is really that it still leaves some issues unresolved then lets do this and tackle the other issues separately. All the best, Michael I personally don't care either way much, but will only do with the Windows installer what the PEP tells me to do (if anything) (more precisely, I remain -0 on changing 2.7, and +0 on changing 3.3). So it comes back to you as the PEP author to take a stance, which you did. It's recommended tradition to record any opposing opinions in the PEP, along with rebuttals, so that the same arguments aren't brought up over and over again. If discussion then settles, it's up to the PEP dictator to approve or reject the whole text. Regards, Martin ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On 7/03/2011 1:55 AM, Paul Moore wrote: On 6 March 2011 02:33, Mark Hammondskippy.hamm...@gmail.com wrote: IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate python2.bat and python3.bat files and put them in System32 with a last installed wins policy. No, no, no! Please no! Bat files are a lousy way of writing wrappers on Windows, as they don't nest. I've lost count of the number of times I've been tripped up by putting a series of commands into a batch file, only to have them fail because somewhere in the middle is a bat file wrapper which makes the outer bat file stop part way through :-( To be clear, I was suggesting that using .bat files in system32 is a close analogy to the *nix situation - I didn't mean to advocate for it to actually happen :) Further, I see the creation of a python3.exe in the Python install directory as quite different than the *nix situation (where the 'python3' link is not in the install dir, but instead in a 'system' dir). IOW, I was trying to point out the solution to the problem on *nix doesn't translate that well to Windows, so Windows should not be considered as part of this PEP. That isn't to suggest Windows should not be considered at all. That said though, I'm only -0 on python2.exe/python3.exe - I don't think it will hurt, but also don't think it will help that much in practice. It may also turn out to be unnecessary should a complete solution be implemented - eg, a python launcher which (a) read the shebang lines and (b) allowed something like python -3 on the command-line would render both python3.exe and requests to have multiple installed Python versions on the PATH redundant. Cheers, Mark ___ 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
On 7/03/2011 10:04 AM, Michael Foord wrote: Paul Moore was +1 on Windows being included. Mark did accept that some of the changes were desirable, but was also concerned they didn't address all the issues on Windows. I *would* like to see all the issues addressed but I think that is outside the scope of this PEP. I simply think Windows is outside the scope of this PEP - the title is The python command on Unix-Like Systems - IMO it should be kept short and focus on exactly what the title says. ... A generic Python launcher that could be used for the file association and honours the Unix style shebang line, delegating to the appropriate version of python, is an interesting idea but out of the scope of this PEP. As above - I think Windows should be kept out of scope. It would be interesting to see if Mark, or others, are strongly opposed to these ideas or have strong preferences. If the biggest downside is really that it still leaves some issues unresolved then lets do this and tackle the other issues separately. As mentioned in my other email, I'm -0 as I think they are slightly misguided. Why not leave the PEP with Unix-like in the title to Unix-like systems and create one with Windows in the title for Windows? :) Cheers, Mark ___ 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
On 3/6/2011 8:18 PM, Mark Hammond wrote: To be clear, I was suggesting that using .bat files in system32 is a close analogy to the *nix situation - I didn't mean to advocate for it to actually happen :) Further, I see the creation of a python3.exe in the Python install directory as quite different than the *nix situation (where the 'python3' link is not in the install dir, but instead in a 'system' dir). IOW, I was trying to point out the solution to the problem on *nix doesn't translate that well to Windows, so Windows should not be considered as part of this PEP. That isn't to suggest Windows should not be considered at all. That said though, I'm only -0 on python2.exe/python3.exe - I don't think it will hurt, but also don't think it will help that much in practice. It may also turn out to be unnecessary should a complete solution be implemented - eg, a python launcher which (a) read the shebang lines and (b) allowed something like python -3 on the command-line would render both python3.exe and requests to have multiple installed Python versions on the PATH redundant. I completely support Mark's repeated request that Windows be left out of the PEP. I'm sure that Guido himself would say that 'include Windows' was meant to be qualified with 'if reasonable and sensible'. To summarize why not 'reasonable and sensible': 1. The solution in the PEP depends on the operating system respecting the shebang line. Windows does not, so the PEP is not appicable, unless we write a launcher that does. But that is outside the scope of the PEP. 2. There is something of a consensus on most of the PEP as is, but less for Windows. The Unix-like PEP should be finalized, approved, and implemented now. Windows can wait. 3. As a Windows user, I would like a *complete* solution that cannot all be part of PEP. It makes no sense to incorporate a partial solution that may be obsoleted by a real Windows install PEP. 4. I think a launcher may be the best idea. If so, other parts of a complete solution will flow from how that is written. 5. The PEP authors cannot write a Windows sub-PEP, so it would require different authors and effectively be a half-PEP in itself anyway. The implementations of the currently PEP and a Windows upgrade would mostly be disjoint also, both in terms of code and authors. -- Terry Jan Reedy ___ 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
On 3/6/2011 7:07 AM, Michael Urman wrote: I think Glenn Linderman hit the use cases on the head; I'm unclear why he was against the overhead of a helper executable. The things I would really want solutions for are these: * double click on a script, and have it launch the right python (2 or 3, w or not) * Probably scan for the final python[.\d]+ string and assume it's relevant. * be able to easily invoke python to interpret a script from the command prompt I'd be comfortable with setting associations to a set of thin executable wrappers which examined the #! line to extract a python version. I'm only against the overhead of a helper written in Python, since it would have to launch Python (some explicit version) to run the helper script, and then launch the right version of Python to execute the real script. You mention a thin executable wrapper, and I have no problem with the overhead of that, probably. Seems that the PEP addresses two sub problems on Unix created by the coexistence of multiple incompatible major versions of Python: (1) how to invoke the right version of the interactive Python from the command line, and (2) how to specify the right version of Python inside Python scripts. One solution solves both problems on Unix... the declaration that /usr/bin/python (generally on the PATH and invocable from the shell as python) may be an installation dependent version, and the creation of appropriate version specific links and/or binaries for specific major and/or minor versions, to be used either from the command line or the #! line of scripts. For Windows, it is true at present that neither of the above problems has a solution: (1) a fully qualified installation path name must be used to invoke any version of Python, since it is not on the PATH (2) Only the last installed version of Python will be invoked by launching a Python script name something-or-another.py Hence, omitting Windows behaviors from the PEP leaves Windows without a solution for either problem, no worse off than it was before, but neither is it better off. If the PEP wants to address (1) interactive launching from the command line on Windows, that could be done by placing a batch file in System32; providing versioned symlinks in installed on a file system that supports them, or providing versioned binaries on a file system that doesn't support symlinks, either in System32, or by adding the Python installation directory to the PATH. For interactive use, most of these solutions are roughly equivalent in function. Since Windows does not use a #! line, then the solutions for (2) must be different. The ones that I can think of are: (A) declare the Python version in the name of the script file. By doing so in the extension, additional Windows associations could be created to launch different versions of Python. Switching versions would be as simple as renaming the file, changing the extension to include a different version. However, various tools would have to learn about additional extensions that mean Python (syntax directed editors, etc.) And it would be hard to have a script in a module, unless the importer recognized all those extensions too. So this solution has ripple effects that make it unattractive, although it is simple to implement the basic feature. (B) declare the Python version in the content of the script file. This cures most of the ripple effects of the above, but requires a launcher or wrapper program to be designed, implemented, and installed. There are a variety of subsolutions for different ways of declaring the version. (B1) Use the Unix #! line, and attempt to parse the version from it. This assumes there is a Unix #! line, note that Windows-only scripts wouldn't need them in the first place. Looking at and interpreting the Unix #! line, and translating it into an invocation of Python on Windows is clever and doable, but very tightly tied to Python. (B2) Use a second #! line, and attempt to parse a whole command from it, using Windows pathname syntax. This is attractive for cross-platform script, and builds on the Unix #! line which is well-understood by Unix and cross-platform developers. Again, Windows-only scripts wouldn't need a Unix #! line, but if this solution uses a second one, then the first must be created, possibly empty. Also, if there are parameters the script needs that only apply to one platform, they could be placed in the appropriate platform's #! line. (B3) Invent a variant syntax for #! -- perhaps #@. Since it is different than #!, it could be on the first line, if no Unix #! line is needed, but if not found on the first line, the second line would be examined, to allow #! on the first line for a cross-platform script. Same costs/benefits as (B2). (B4) As a variation on (B2) or (B3), the declaration of the version would not have to be a command line format... it could be #@ Version 3.2,
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
On 7/03/2011 3:30 PM, Glenn Linderman wrote: I'm only against the overhead of a helper written in Python, since it would have to launch Python (some explicit version) to run the helper script, and then launch the right version of Python to execute the real script. You mention a thin executable wrapper, and I have no problem with the overhead of that, probably. Yeah - I think any such wrapper could be a reasonably small C program - although I guess that depends on the decided functionality :) ... Since Windows does not use a #! line, then the solutions for (2) must be different. The ones that I can think of are: (A) declare the Python version in the name of the script file. By doing so in the extension, additional Windows associations could be created to launch different versions of Python. Switching versions would be as simple as renaming the file, changing the extension to include a different version. However, various tools would have to learn about additional extensions that mean Python (syntax directed editors, etc.) And it would be hard to have a script in a module, unless the importer recognized all those extensions too. So this solution has ripple effects that make it unattractive, although it is simple to implement the basic feature. Agreed - I find this unattractive. (B) declare the Python version in the content of the script file. This cures most of the ripple effects of the above, but requires a launcher or wrapper program to be designed, implemented, and installed. There are a variety of subsolutions for different ways of declaring the version. snip a few options Without putting too much thought into it, I think a simple scheme could work where the path must either be /usr/bin/python[23]? or a fully-qualified path to a Python executable. IIUC, this should allow most scripts to have a shebang line that does the right thing on *nix and Windows systems while still offering maximum flexibility on Windows. By default, for Python, the wrapper would get associated only with .py files. There would probably also need to be the same for .pyw, but it would be almost identical to the .py handling. Cheers, Mark ___ 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
On Mon, Mar 7, 2011 at 3:02 PM, Kerrick Staley m...@kerrickstaley.com wrote: 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. Indeed. Terry spelled out the reasons for a separate Windows specific PEP pretty well, so I'll add a reference to that in the next PEP update. 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] Support the /usr/bin/python2 symlink upstream
On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammond skippy.hamm...@gmail.com wrote: Without putting too much thought into it, I think a simple scheme could work where the path must either be /usr/bin/python[23]? or a fully-qualified path to a Python executable. IIUC, this should allow most scripts to have a shebang line that does the right thing on *nix and Windows systems while still offering maximum flexibility on Windows. Such a scheme should be able to handle /usr/bin/env python2 and variants as well. 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] Support the /usr/bin/python2 symlink upstream
On 7/03/2011 4:34 PM, Nick Coghlan wrote: On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammondskippy.hamm...@gmail.com wrote: Without putting too much thought into it, I think a simple scheme could work where the path must either be /usr/bin/python[23]? or a fully-qualified path to a Python executable. IIUC, this should allow most scripts to have a shebang line that does the right thing on *nix and Windows systems while still offering maximum flexibility on Windows. Such a scheme should be able to handle /usr/bin/env python2 and variants as well. Agreed - that is just my ignorance showing through :) Cheers, Mark ___ 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
On 05/03/2011 07:02, Nick Coghlan wrote: On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammondmhamm...@skippinet.com.au wrote: I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the last installed wins issue Martin mentions - only all of them taken together will fix this issue - not that I personally consider it particularly broken - more like sub-optimal :) I updated the draft PEP, explicitly bringing Mac OS X and Cygwin within the scope of the recommendation, and excluding PYTHON* environment variable considerations and Windows-related proposals. The Windows section does include a hit-list that may serve as a useful starting point if someone else felt like starting a Windows specific PEP, though. The issues are relevant to Windows (there are *other* issues as well but that doesn't mean that the same issue doesn't apply). Guido also said he would like to see Windows addressed. I'll be happy to try and come to some consensus with Martin (and others) on what we *can* do for Windows (as similar to the other platforms as possible would be my goal) and provide appropriate text for the PEP. I don't think it would be good (or necessary) to split this into a separate PEP. PyCon (sprints or language summit) would be a good place to talk about this. I believe the only remaining decision to be made is whether we actually change the make install command and the Mac OS X installers for Python 2.7.2, or leave them alone and tell the distro folks to fix it on their side of the fence. My own vote is a +1 for both, since changing make install is fairly easy, and Ronald indicated earlier in the thread that not only is the change to the Mac OS X installer pretty trivial, but that Apple are likely to follow the lead of whatever our default installer does. Martin has also indicated that making appropriate changes to the Windows installer would not be difficult if we agree that changing the 2.7 maintenance branch in this way is appropriate. All the best, Michael Foord Full PEP: http://www.python.org/dev/peps/pep-0394/ Diff to previous version: http://svn.python.org/view/peps/trunk/pep-0394.txt?r1=88743r2=88753 Cheers, Nick. -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On Sat, Mar 5, 2011 at 11:37 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I don't think it would be good (or necessary) to split this into a separate PEP. PyCon (sprints or language summit) would be a good place to talk about this. Sure. With a PEP to record decisions this time, we shouldn't get a repeat of the last naming discussion where I believe the only remaining decision to be made is whether we actually change the make install command and the Mac OS X installers for Python 2.7.2, or leave them alone and tell the distro folks to fix it on their side of the fence. My own vote is a +1 for both, since changing make install is fairly easy, and Ronald indicated earlier in the thread that not only is the change to the Mac OS X installer pretty trivial, but that Apple are likely to follow the lead of whatever our default installer does. Martin has also indicated that making appropriate changes to the Windows installer would not be difficult if we agree that changing the 2.7 maintenance branch in this way is appropriate. True, it's only the more exotic ideas (like trying to do something about the PYTHON* variables or file associations) that become an issue. Simply supporting having a python3 version and a python2 version on PATH at the same time could work by duplicating the main executables (using python2w and python3w for the non-console variants), with the sysadmin effectively choosing the preferred version of the installed versions based on the directory order in PATH. 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] Support the /usr/bin/python2 symlink upstream
On Sun, Mar 6, 2011 at 12:22 AM, Nick Coghlan ncogh...@gmail.com wrote: On Sat, Mar 5, 2011 at 11:37 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I don't think it would be good (or necessary) to split this into a separate PEP. PyCon (sprints or language summit) would be a good place to talk about this. Sure. With a PEP to record decisions this time, we shouldn't get a repeat of the last naming discussion where ... people forgot precisely which decisions were made and their rationale. Oops :) 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] Support the /usr/bin/python2 symlink upstream
On 05/03/2011 14:22, Nick Coghlan wrote: [snip...] Martin has also indicated that making appropriate changes to the Windows installer would not be difficult if we agree that changing the 2.7 maintenance branch in this way is appropriate. True, it's only the more exotic ideas (like trying to do something about the PYTHON* variables or file associations) that become an issue. Right. But those are issues *anyway* and are orthogonal to this particular one. (And in the case of PYTHON* environment variables not restricted to windows and not addressed by this PEP for any platform.) Simply supporting having a python3 version and a python2 version on PATH at the same time could work by duplicating the main executables (using python2w and python3w for the non-console variants), with the sysadmin effectively choosing the preferred version of the installed versions based on the directory order in PATH. Yes. I would also like to see python27.exe and python32.exe (etc) but that may be a step too far (although Martin was open to it we'll have to see what final agreement we come to). All the best, Michael Cheers, Nick. -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On 05/03/2011 00:47, Mark Hammond wrote: On 5/03/2011 8:21 AM, Martin v. Löwis wrote: ... As for Windows support: we currently don't install a python3.exe binary, let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll adjust the installer if the PEP asks me to. For the reasons discussed, I'm -0 on the change (i.e. double-clicking .py will continue to launch the most-recently installed Python, rather than the right one, and setting PYTHONPATH will continue to break installations). I agree with the -0 - I simply don't think it will, in practice, make anyone's life much easier. To run python2 and python3 based scripts in the same environment already requires some manual work by the machine owner (both directories will need to be added to the path) so the additional burden of some other steps (eg, .bat files, doskey alaises etc) doesn't seem that great. There is also a small risk of confusion - people may believe python.exe and python2.exe/python3.exe have different purposes and be confused about when to use which. In order to follow the most basic of Python tutorials new users do have to manually add their Python install to the PATH. This is unfortunate and should be addressed as a separate issue. I don't see this as a good reason for not taking additional steps to support multiple versions side-by-side on Windows. Having python2.x / python3.x binaries isn't as confusing for users on other platforms I don't see why it should be on Windows. If we add versioned binaries then users manually adding their Python install to the PATH see a benefit; they can specify the version of Python without additional work on their part. If we later add support for automatically adding Python installs to the PATH (optionally - preferably on by default) then all users who use the command line see a benefit. All the best, Michael Foord I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the last installed wins issue Martin mentions - only all of them taken together will fix this issue - not that I personally consider it particularly broken - more like sub-optimal :) Cheers, Mark ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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
On 6/03/2011 12:37 AM, Michael Foord wrote: On 05/03/2011 07:02, Nick Coghlan wrote: On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammondmhamm...@skippinet.com.au wrote: I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the last installed wins issue Martin mentions - only all of them taken together will fix this issue - not that I personally consider it particularly broken - more like sub-optimal :) I updated the draft PEP, explicitly bringing Mac OS X and Cygwin within the scope of the recommendation, and excluding PYTHON* environment variable considerations and Windows-related proposals. The Windows section does include a hit-list that may serve as a useful starting point if someone else felt like starting a Windows specific PEP, though. The issues are relevant to Windows (there are *other* issues as well but that doesn't mean that the same issue doesn't apply). Guido also said he would like to see Windows addressed. What issues specifically? If I look at the current PEP language, it refers to the default version of the Python interpreter and all new code that needs to invoke the Python interpreter. Neither of these apply in any meaningful way to Windows. It could be argued that the latter could include .bat files which use Python but that sounds like a theoretical problem (ie, I haven't heard much noise about that) where PEP394 is addressing an observed practical problem. On Windows it seems to be just about 'python2' and 'python3' doing the correct thing in a default command prompt, which while desirable ignores the broader issues (eg, the file associations and anything else windowsy and not driven by the command-prompt) I'll be happy to try and come to some consensus with Martin (and others) on what we *can* do for Windows (as similar to the other platforms as possible would be my goal) and provide appropriate text for the PEP. IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate python2.bat and python3.bat files and put them in System32 with a last installed wins policy. The fact this doesn't help users installing Python just for me is fine too from the POV of matching *nix systems - a user installing a private Python build on *nix also doesn't get the python2 and python3 conveniences, nor the automatic PATH convenience. But in practice I expect this would *not* be OK - which just highlights the risks of trying to generalize a specific observed problem on one OS to others. Cheers, Mark ___ 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
Folks, please stop CC'ing p...@python.org for non-PEP submissions. They all get held for moderator approval. I've approved a few of them, but I'm going to start rejecting them (so you get a bounce :) unless the message actually contains a PEP. cheerfully-co-editing-peps-ly y'rs, -Barry signature.asc Description: PGP signature ___ 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
On Sat, Mar 5, 2011 at 1:10 AM, Barry Warsaw ba...@python.org wrote: Folks, please stop CC'ing p...@python.org for non-PEP submissions. They all get held for moderator approval. I've approved a few of them, but I'm going to start rejecting them (so you get a bounce :) unless the message actually contains a PEP. Sorry, I didn't even notice that was on the CC list. Don't add the PEP, I already created PEP 394 for it :) 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] Support the /usr/bin/python2 symlink upstream
On Mar 05, 2011, at 01:33 AM, Nick Coghlan wrote: On Sat, Mar 5, 2011 at 1:10 AM, Barry Warsaw ba...@python.org wrote: Folks, please stop CC'ing p...@python.org for non-PEP submissions. They all get held for moderator approval. I've approved a few of them, but I'm going to start rejecting them (so you get a bounce :) unless the message actually contains a PEP. Sorry, I didn't even notice that was on the CC list. Don't add the PEP, I already created PEP 394 for it :) Thanks! -Barry signature.asc Description: PGP signature ___ 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
Is there any discussion still going on about the details of the PEP
(now PEP 394)? I'm in favor of the general idea. What about Windows? I
think it should be the same there if possible.
The only thing I note is that the PEP doesn't explicitly state (unless
I missed it) that python should invoke the same Python binary as
either python2 or python3 and not some other version of Python
{2,3}.x (at least not until python4 is being considered :-).
Similarly, python2 and python3 should refer to one of the existing
python2.x or python3.x binary and not some other one.
--
--Guido van Rossum (python.org/~guido)
___
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
Am 04.03.2011 20:14, schrieb Guido van Rossum: Is there any discussion still going on about the details of the PEP (now PEP 394)? I'm in favor of the general idea. What about Windows? I think it should be the same there if possible. I think a key issue is whether to change future 2.7 bug fix releases or not. People have been opposed to the very notion of adding this feature in a bug fix release; not sure how they feel if the change is PEP-sanctioned. As for Windows support: we currently don't install a python3.exe binary, let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll adjust the installer if the PEP asks me to. For the reasons discussed, I'm -0 on the change (i.e. double-clicking .py will continue to launch the most-recently installed Python, rather than the right one, and setting PYTHONPATH will continue to break installations). Regards, Martin ___ 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
On Mar 4, 2011, at 4:21 PM, Martin v. Löwis wrote: and setting PYTHONPATH will continue to break installations). Indeed, it's really *quite* unfortunate that the proposal to make python3 use PYTHON3PATH instead of PYTHONPATH was rejected. 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/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
On Mar 4, 2011, at 4:21 PM, Martin v. Löwis wrote: Am 04.03.2011 20:14, schrieb Guido van Rossum: Is there any discussion still going on about the details of the PEP (now PEP 394)? I'm in favor of the general idea. What about Windows? I think it should be the same there if possible. I think a key issue is whether to change future 2.7 bug fix releases or not. People have been opposed to the very notion of adding this feature in a bug fix release; not sure how they feel if the change is PEP-sanctioned. I personally don't think it's necessary to change Python 2's build. Distros can easily do it, pointing to the PEP for justification. But I'm also not strongly opposed, so -0 from me. -Barry ___ 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
On Fri, Mar 4, 2011 at 1:21 PM, Martin v. Löwis mar...@v.loewis.de wrote: Am 04.03.2011 20:14, schrieb Guido van Rossum: Is there any discussion still going on about the details of the PEP (now PEP 394)? I'm in favor of the general idea. What about Windows? I think it should be the same there if possible. I think a key issue is whether to change future 2.7 bug fix releases or not. People have been opposed to the very notion of adding this feature in a bug fix release; not sure how they feel if the change is PEP-sanctioned. Personally I think this is fine -- it 's not like this is affecting language or library compatibility, but doing this from now on emphasizes that this is what we want distros to do. As far as I'm concerned we could go further and add creation of the python2 symlink to the make install target for new bugfix releases of older versions too. As for Windows support: we currently don't install a python3.exe binary, let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll adjust the installer if the PEP asks me to. For the reasons discussed, I'm -0 on the change (i.e. double-clicking .py will continue to launch the most-recently installed Python, rather than the right one, and setting PYTHONPATH will continue to break installations). I'm not a Windows user so I'll leave this part to the group of interested developers to reach consensus. -- --Guido van Rossum (python.org/~guido) ___ 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
On Fri, 2011-03-04 at 22:21 +0100, Martin v. Löwis wrote: As for Windows support: we currently don't install a python3.exe binary, let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll adjust the installer if the PEP asks me to. For the reasons discussed, I'm -0 on the change (i.e. double-clicking .py will continue to launch the most-recently installed Python, rather than the right one, and setting PYTHONPATH will continue to break installations). I think the python2.exe or python3.exe (or both) for Windows would be a good idea. I also think we need to seriously consider fixing the double-click action for Windows. .py2 and .py3 extensions could work, but seems clumsy. ___ 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
On 5/03/2011 8:21 AM, Martin v. Löwis wrote: ... As for Windows support: we currently don't install a python3.exe binary, let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll adjust the installer if the PEP asks me to. For the reasons discussed, I'm -0 on the change (i.e. double-clicking .py will continue to launch the most-recently installed Python, rather than the right one, and setting PYTHONPATH will continue to break installations). I agree with the -0 - I simply don't think it will, in practice, make anyone's life much easier. To run python2 and python3 based scripts in the same environment already requires some manual work by the machine owner (both directories will need to be added to the path) so the additional burden of some other steps (eg, .bat files, doskey alaises etc) doesn't seem that great. There is also a small risk of confusion - people may believe python.exe and python2.exe/python3.exe have different purposes and be confused about when to use which. I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the last installed wins issue Martin mentions - only all of them taken together will fix this issue - not that I personally consider it particularly broken - more like sub-optimal :) Cheers, Mark ___ 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
On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammond mhamm...@skippinet.com.au wrote: I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the last installed wins issue Martin mentions - only all of them taken together will fix this issue - not that I personally consider it particularly broken - more like sub-optimal :) I updated the draft PEP, explicitly bringing Mac OS X and Cygwin within the scope of the recommendation, and excluding PYTHON* environment variable considerations and Windows-related proposals. The Windows section does include a hit-list that may serve as a useful starting point if someone else felt like starting a Windows specific PEP, though. I believe the only remaining decision to be made is whether we actually change the make install command and the Mac OS X installers for Python 2.7.2, or leave them alone and tell the distro folks to fix it on their side of the fence. My own vote is a +1 for both, since changing make install is fairly easy, and Ronald indicated earlier in the thread that not only is the change to the Mac OS X installer pretty trivial, but that Apple are likely to follow the lead of whatever our default installer does. Full PEP: http://www.python.org/dev/peps/pep-0394/ Diff to previous version: http://svn.python.org/view/peps/trunk/pep-0394.txt?r1=88743r2=88753 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
