Rename python.exe to python3.exe on Windows
Hello, On most *nix systems, Python 3.x is available as the python3 executable, and Python 2.x as the 'python' executable. This lets both exist side-by-side and be usable from the command-line. The alternative (used by Arch), is to name Python 2.x 'python2', and 3.x 'python'. The Windows distribution of Python does neither, it names them both 'python.exe', meaning that you can't install and use both at once. Moreover, if you install Python 2.7 and then Python 3.2, the default handler for .py files is set to Python 3.2, and changing it to 2.7 is difficult because of a quirk in Eexplorer that forces you to choose between two non-distinguishable "python.exe"s. This is made much more difficult if in fact you installed five or so different Python versions. Also any automated tests using something like Cram that use python3 will not work, and any batch scripts that use python.exe will work differently depending on the host system. (It wouldn't be awful to get python-X.Y.exe executables, either). The downside of this is that any code that tries to use C:\Python3Y\python.exe breaks. Such code is probably broken anyway, there are multiple Ys around, and Python can be installed in My Documents or wherever. PEP 397 should relieve the issues with opening .py files, making some of this unnecessary with that change, as well. I'm guessing that it would also be appropriate to rename pythonw.exe to python3w.exe. I doubt that particular change matters at all, it's solely to do with opening .pyw files, and that should be handled by PEP 397. I'd appreciate any thoughts or comments you might have. Thanks for your time, Devin Jeanpierre
Devin Jeanpierre <jeanpierreda@gmail.com> writes:
More importantly, it ensures that programs written for older Python 2.x will continue to run with the default ‘python’. If the default ‘python’ were Python 3.x, programs expecting Python 2.x would most likely break due to backward incompatibility. So it's best if the ‘python’ program invokes only Python 2.x. -- \ “To label any subject unsuitable for comedy is to admit | `\ defeat.” —Peter Sellers | _o__) | Ben Finney
Ben Finney wrote:
The first sentence is true. The second is a value judgement, not a statement of fact, and the people behind Arch Linux disagree with you. http://www.archlinux.org/news/python-is-now-python-3/ I say, good on 'em. I wish I could find the quote somebody made about Arch being the distro that makes Gentoo seem cautious and conservative... something about Arch moving forward so the Gentoo folks know which mistakes not to make? -- Steven
Steven D'Aprano writes:
The only thing history teaches us is that nobody learns from others' history: $ python Python 3.1.3 (r313:86834, Feb 22 2011, 18:52:21) [GCC 4.3.5] on linux2 Type "help", "copyright", "credits" or "license" for more information.
$
There are a couple of ebuilds that break because of this.
I would say in every Python installation there should be a binary with the version number attached. I think in most (all?) Linux distributions this is already the case. E.g. there is python2.7 and python3.2. There is also python2, that links to some python2.x, and python3 that links to some python3.x, and then there is python, that links to any of the above. Under Linux/Mac OS X we already add a line like this to our scripts: #!/usr/bin/env python Or better: #!/usr/bin/env python3 I say it should be documented that the first is deprecated and the latter form shall be used. Using "#!/usr/bin/env python" should mean "this script is written so that it can be run in *any* python version", which is pretty unrealistic. "#!/usr/bin/env python3" should mean "this script is written so that it can be run in any python 3.x version" and so on. Of course there are scripts that do not use this right. They should be considered as broken and be fixed. (Maybe print deprecation warnings if possible?) Now on Windows there is no #! mechanism. I think it would be worthwhile to fix this and implement a python-dispatcher for Windows. This would then parse the #!-line, drop the "/usr/bin/env" part (if it exists) and lookup the right Python binary form a registry variable. I don't know if there are any registry variables set in a Windows Python installation that let you find the binary of a certain version, but I think it would be a good thing. This way correct scripts would just work under Unix (Linux, Mac, BSD) and Windows. And under Windows you would not have any problems with file type associations. *.py and *.pyw files just have to be associated with the dispatcher. It should not matter if the dispatcher is from a Python 2.x or Python 3.x installation. -panzi On 05/09/2011 12:39 PM, Stephen J. Turnbull wrote:
On Tue, May 10, 2011 at 2:43 AM, Mathias Panzenböck <grosser.meister.morti@gmx.net> wrote:
Since this came up not all that long ago, I'll point people to PEP 394 (for the current draft recommendation regarding symlinks on *nix systems) and PEP 397 (for proposed Windows launcher semantics). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I think going the Arch route might be unrealistic, because there will be no Python 2.8, and thus no chance to rename python.exe to python2.exe. Arch can do it because they have their own distribution of Python, Microsoft Windows does not. All I can think of is having Python 3 installers also install symlinks or batch scripts for Python 2 installations. This could break because you might install a Python 2 installation after Python 3 (and in an unexpected place, if the installer tries to predict things). If 3.3 has its executable renamed, the worst situation is that python refers to 3.1 or 3.2, and python3 to 3.3. This could be resolved by removing 3.2 or 3.1 from the PATH (and if you still wanted to access them, adding python31.exe and python32.exe symlinks somewhere on the PATH). This situation is increasingly unlikely to occur as time goes on and fewer people put 3.2 or 3.1 on the PATH at all. Devin Jeanpierre On Sat, May 7, 2011 at 10:28 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Devin Jeanpierre <jeanpierreda@gmail.com> writes:
More importantly, it ensures that programs written for older Python 2.x will continue to run with the default ‘python’. If the default ‘python’ were Python 3.x, programs expecting Python 2.x would most likely break due to backward incompatibility. So it's best if the ‘python’ program invokes only Python 2.x. -- \ “To label any subject unsuitable for comedy is to admit | `\ defeat.” —Peter Sellers | _o__) | Ben Finney
Ben Finney wrote:
The first sentence is true. The second is a value judgement, not a statement of fact, and the people behind Arch Linux disagree with you. http://www.archlinux.org/news/python-is-now-python-3/ I say, good on 'em. I wish I could find the quote somebody made about Arch being the distro that makes Gentoo seem cautious and conservative... something about Arch moving forward so the Gentoo folks know which mistakes not to make? -- Steven
Steven D'Aprano writes:
The only thing history teaches us is that nobody learns from others' history: $ python Python 3.1.3 (r313:86834, Feb 22 2011, 18:52:21) [GCC 4.3.5] on linux2 Type "help", "copyright", "credits" or "license" for more information.
$
There are a couple of ebuilds that break because of this.
I would say in every Python installation there should be a binary with the version number attached. I think in most (all?) Linux distributions this is already the case. E.g. there is python2.7 and python3.2. There is also python2, that links to some python2.x, and python3 that links to some python3.x, and then there is python, that links to any of the above. Under Linux/Mac OS X we already add a line like this to our scripts: #!/usr/bin/env python Or better: #!/usr/bin/env python3 I say it should be documented that the first is deprecated and the latter form shall be used. Using "#!/usr/bin/env python" should mean "this script is written so that it can be run in *any* python version", which is pretty unrealistic. "#!/usr/bin/env python3" should mean "this script is written so that it can be run in any python 3.x version" and so on. Of course there are scripts that do not use this right. They should be considered as broken and be fixed. (Maybe print deprecation warnings if possible?) Now on Windows there is no #! mechanism. I think it would be worthwhile to fix this and implement a python-dispatcher for Windows. This would then parse the #!-line, drop the "/usr/bin/env" part (if it exists) and lookup the right Python binary form a registry variable. I don't know if there are any registry variables set in a Windows Python installation that let you find the binary of a certain version, but I think it would be a good thing. This way correct scripts would just work under Unix (Linux, Mac, BSD) and Windows. And under Windows you would not have any problems with file type associations. *.py and *.pyw files just have to be associated with the dispatcher. It should not matter if the dispatcher is from a Python 2.x or Python 3.x installation. -panzi On 05/09/2011 12:39 PM, Stephen J. Turnbull wrote:
On Tue, May 10, 2011 at 2:43 AM, Mathias Panzenböck <grosser.meister.morti@gmx.net> wrote:
Since this came up not all that long ago, I'll point people to PEP 394 (for the current draft recommendation regarding symlinks on *nix systems) and PEP 397 (for proposed Windows launcher semantics). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I think going the Arch route might be unrealistic, because there will be no Python 2.8, and thus no chance to rename python.exe to python2.exe. Arch can do it because they have their own distribution of Python, Microsoft Windows does not. All I can think of is having Python 3 installers also install symlinks or batch scripts for Python 2 installations. This could break because you might install a Python 2 installation after Python 3 (and in an unexpected place, if the installer tries to predict things). If 3.3 has its executable renamed, the worst situation is that python refers to 3.1 or 3.2, and python3 to 3.3. This could be resolved by removing 3.2 or 3.1 from the PATH (and if you still wanted to access them, adding python31.exe and python32.exe symlinks somewhere on the PATH). This situation is increasingly unlikely to occur as time goes on and fewer people put 3.2 or 3.1 on the PATH at all. Devin Jeanpierre On Sat, May 7, 2011 at 10:28 PM, Steven D'Aprano <steve@pearwood.info> wrote:
participants (6)
-
Ben Finney -
Devin Jeanpierre -
Mathias Panzenböck -
Nick Coghlan -
Stephen J. Turnbull -
Steven D'Aprano