On 8 March 2016 at 11:22, Victor Stinner wrote:

2016-03-08 10:24 GMT+01:00 Paul Moore :

...

The "py.exe" wrapper on Windows runs the latest Python version available on the user's PC, but it prefers Python 2 if the user has both Python 2 and 3 installed. With Python 3.5 being released, is it not about time that we switched that default to always prefer the latest version available?

On UNIX, it was decided to have python2 and python3 and don't guess user expectations.

Why not providing an py3 runner which uses Python 3 by default?

I don't know. Personally, I don't like the versioned executables (will we get a py4, py5,...?) but that's just a personal preference. I believe that with an unversioned executable it should use the latest version by default, and the point of my email is that I think we're now at a point where special casing Python 2 is unreasonable, particularly on Windows where there is no tradition of a "system Python" which needs to be Python 2. If someone *else* wants to propose replacing py.exe with py2.exe and py3.exe then they can do that (and I'll be -1 on that proposal). You don't mention the fact that an unadorned "python" command on Unix typically invokes Python 2. As far as I know the only reason that was needed was because system Python scripts were written that way, back before Python 3 was around, and couldn't be updated to be Python 3 compatible. That reason doesn't apply on Windows. And on Windows, "python" has always referred to the currently active version of Python, whether 2 or 3. tl; dr; I'm against making the unversioned name "python" (or "py") forever mean Python 2. There are justifications for it on Unix, but none of those apply on Windows. Paul

On 08/03/2016 15:03, Chris Angelico wrote:

On Wed, Mar 9, 2016 at 12:17 AM, Paul Moore wrote:

...

tl; dr; I'm against making the unversioned name "python" (or "py") forever mean Python 2. There are justifications for it on Unix, but none of those apply on Windows.

https://www.python.org/dev/peps/pep-0394/#exclusion-of-ms-windows

On Unix, yes, but not on Windows.

+1 for making py.exe now default to Python 3.

ChrisA

+1 from me as well, it's irritating having to type "py -3" every time. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On 03/08/2016 01:11 PM, Alexander Walters wrote:

-1 py.exe should use whatever was first installed by default. If that's 2.7, then it's 2.7. if its python 9.9, then its python 9.9. but it should use whatever was FIRST installed unless the user changes it.

Which is still asking for a change from what happens now; i.e. if 3.3 is installed first, then 2.7, py.exe will default to 2.7. I agree whichever is first installed should be default; I also think installer should have an option to change the py.exe default to the version being installed. -- ~Ethan~

On 3/8/2016 16:29, Ian Kelly wrote:

On Tue, Mar 8, 2016 at 2:17 PM, Ethan Furman wrote:

...

On 03/08/2016 01:11 PM, Alexander Walters wrote:

...

-1 py.exe should use whatever was first installed by default. If that's 2.7, then it's 2.7. if its python 9.9, then its python 9.9. but it should use whatever was FIRST installed unless the user changes it.

Which is still asking for a change from what happens now; i.e. if 3.3 is installed first, then 2.7, py.exe will default to 2.7.

I agree whichever is first installed should be default; I also think installer should have an option to change the py.exe default to the version being installed. It would also be nice to have a way to change the default without needing to rerun an installer. I am all for more configuration ex post facto. We are talking about the tyranny of the default though, which is complicated by the fact that it wont see the light of day until 3.6 (unless we backport a modified version of py.exe in future releases of 2.7 and 3.*).

On 8 March 2016 at 22:00, Steve Dower wrote:

"First installed" is a very difficult proposition, especially if you want versions of Python pre-3.6 to participate. "Last installed" is slightly better, though not easy to do without triggering systems that detect corrupted installations.

Also, any dependency on installation order gets *very* messy if someone installs and uninstalls various versions. What does the default become if I uninstall the version that was previously the first (or last) installed? Would we need to keep details of precisely when everything was installed?

Personally I think "latest version" is the best default (compared to the current "latest 2.x version"), so I'm +1 on removing the assumption that "PY_PYTHON" is "2" by default.

Latest version has the additional advantage of being essentially the current behaviour, just with the special case of "but prefer Python 2 over Python 3 if both are present" removed. (Note that technically the current rule is not simply "latest 2.x version", as if the user only has Python 3 installed, the latest 3.x version is used). The only other option I can think of is "use the one the user selected as the default Python (i.e., introspect the association for ".py" files) but even then we need a default default (!) for people who don't select any default Python. It's also messy to implement. And it's a bigger change from current behaviour.

Users can change their own default with any of the mechanisms described at https://docs.python.org/3/using/windows.html#customization

Absolutely. This should *only* apply when there is no user customisation - and it needs no further configurability, because the current methods are perfectly sufficient. Paul

On Wed, Mar 9, 2016 at 2:59 PM, Alexander Walters wrote:

How about the better option: No default preset default.. Make the user pick every time it's installed.

Or the best option of them all: call Python 3... python3.exe and the shell launcher py3.exe.

Or stop it with the launcher.

Have a read of PEP 397 if you want to know why the launcher exists. https://www.python.org/dev/peps/pep-0397/ ChrisA

On 03/08/2016 08:06 PM, Alexander Walters wrote:

But who does that actually help? I contest this attempts to solve a problem (in the wrong way) that does not actually exist.

If you don't like it, ignore it. It helps me. -- ~Ethan~

On 03/08/2016 08:17 PM, Alexander Walters wrote:

I cant ignore it because it modifies my system when I install python, and is a massive pain to scrub off the system if it accidentally gets installed.

Really? I thought it only installed two files into the windows directory? -- ~Ethan~

On Tue, Mar 8, 2016 at 11:06 PM, Alexander Walters wrote:

On 3/8/2016 23:05, Chris Angelico wrote:

...

Have a read of PEP 397 if you want to know why the launcher exists.

https://www.python.org/dev/peps/pep-0397/

ChrisA

But who does that actually help? I contest this attempts to solve a problem (in the wrong way) that does not actually exist.

Linux users are used to being able to type "./script.py" on the command line and have the shebang tell the OS which version of Python to use. Windows doesn't support that because it instead works off of associating the file extension globally with an individual program, so ".py" can only be associated with a single executable, which is unworkable if you have both python2 and python3 scripts. py.exe solves that problem. So unless you have an alternative solution to enable Unix-like script launching with multiple Python versions from the command line, proposing to eliminate py.exe is a non-starter, at least with me. On Tue, Mar 8, 2016 at 11:22 PM, Alexander Walters wrote:

It modifies the windows registry to set a file association, which is a pain when you want double clicking a python file to open a text editor. So you have to change file associations, which was made really painful in recent versions of windows.

So add an option to the installer to not set that file association. It's been a while since I installed a Python on my Windows machine, but IIRC that option may already be there (I could be mistaken, though).

On Tue, Mar 08, 2016 at 11:32:34PM -0500, Alexander Walters wrote:

Windows is not *nix. Supporting *nix idioms should not be a priority.

Python is over two decades old and we're up to version 3.5. You can hardly call this "a priority". It's been a long time coming. Besides, it surely depends on whether or not the idiom in question is valuable. Windows, and DOS before it, has copied many idioms from Unix over the years, as Unix/Linux have copied from Windows. For better or worse.

...

So add an option to the installer to not set that file association. It's been a while since I installed a Python on my Windows machine, but IIRC that option may already be there (I could be mistaken, though).

It's there, and VERY easy to miss. Once installed, it is a pain to get rid of, since the uninstaller does NOT take it out.

Then you should submit a bug or enhancement request to have that fixed. -- Steve

On 9 March 2016 at 14:06, Alexander Walters wrote:

On 3/8/2016 23:05, Chris Angelico wrote:

...

Have a read of PEP 397 if you want to know why the launcher exists.

https://www.python.org/dev/peps/pep-0397/

But who does that actually help? I contest this attempts to solve a problem (in the wrong way) that does not actually exist.

Volunteers don't generally donate their time to solve problems they don't have (and employers don't typically donate their employees' time to solve problems they or their customers don't have), which means "I don't personally have that problem, so I deny its very existence" is almost never a compelling line of argument in a community-driven open source project. In this case, we needed a cross-platform way for Python 3 scripts to indicate they were Python 3 only, and Python 2 scripts to indicate they were Python 2 only. *nix already had a way to indicate that via shebang lines, so it was natural to make that existing solution also work on Windows, rather than inventing something Windows specific (which would rather defeat the "cross-platform" objective). The fact that the chosen implementation strategy also made the "py" launcher usable at the command line was more of a side effect than the primary purpose of the exercise. In that regard, I think the meaning of "Make py.exe default to Python 3" as proposed in this thread needs to be spelled out more explicitly. If the proposal is to change the default behaviour for: * launching the interactive interpreter * running scripts without a shebang line * running scripts with an unrecognised shebang line then I think it's reasonable to switch all those to default to the newest CPython runtime on the machine, regardless of whether that's Python 2 or Python 3. However, if the proposal is also to change the handling of the following shebang lines: * #!/usr/bin/python * #!/usr/local/bin/python * #!/usr/bin/env python * #!python then I think those should continue to be handled in a manner consistent with PEP 394 (and as PEP 397 currently specifies): as referring to Python 2 (unless PY_PYTHON explicitly says otherwise or only Python 3 is available). Independently of the main topic of the thread, it does sound to me like there may be a valid enhancement request for the Windows installer to add a "Repair" mode that allows some of these settings (like adding or removing the file association) to be changed post-installation. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Wed, Mar 9, 2016 at 4:32 PM, Nick Coghlan wrote:

If the proposal is to change the default behaviour for:

* launching the interactive interpreter * running scripts without a shebang line * running scripts with an unrecognised shebang line

then I think it's reasonable to switch all those to default to the newest CPython runtime on the machine, regardless of whether that's Python 2 or Python 3.

However, if the proposal is also to change the handling of the following shebang lines:

* #!/usr/bin/python * #!/usr/local/bin/python * #!/usr/bin/env python * #!python

then I think those should continue to be handled in a manner consistent with PEP 394 (and as PEP 397 currently specifies): as referring to Python 2 (unless PY_PYTHON explicitly says otherwise or only Python 3 is available).

Agree with both of these points. AIUI the original proposal was solely about the first half, with no recommendation of change to the second. What does py.exe do with a "#!/usr/bin/python" if the only Python installed is 3.5? Does it run it under 3.5, or error out? ChrisA

On Wed, Mar 9, 2016 at 3:47 AM, Paul Moore wrote:

I don't disagree with limiting the change to not affect unversioned shebang lines, but I'm not sure how much effort I'd personally be willing to put into special-casing that. We can see on that one when I start to look at the actual code, I guess...

I agree with Nick that Python 2 compatibility should be maintained for virtual paths in shebangs. I think a straight-forward solution is for locate_python() to gain a "virtual_mode" BOOL parameter, which is TRUE only when processing a virtual shebang, i.e. when called from maybe_handle_shebang(). For example, when wanted_ver is empty, locate_python would search the following sequence: configured_value = get_configured_value(config_key); if (configured_value) result = find_python_by_version(configured_value); if (result == NULL) result = find_python_by_version(virtual_mode ? L"2" : L"3"); if (result == NULL) result = find_python_by_version(virtual_mode ? L"3" : L"2"); This change works for me with various combinations of enabled PythonCore registry keys, PY_PYTHON values, and shebang lines. Note that the behavior of the plain "#!python" virtual shebang gets lumped in with virtual Unix paths, but I don't know why anyone would add this shebang without a target version.

On 09/03/2016 13:21, Paul Moore wrote:

On 9 March 2016 at 12:49, eryk sun wrote:

...

On Wed, Mar 9, 2016 at 3:47 AM, Paul Moore wrote:

...

I don't disagree with limiting the change to not affect unversioned shebang lines, but I'm not sure how much effort I'd personally be willing to put into special-casing that. We can see on that one when I start to look at the actual code, I guess...

I agree with Nick that Python 2 compatibility should be maintained for virtual paths in shebangs. I think a straight-forward solution is for locate_python() to gain a "virtual_mode" BOOL parameter, which is TRUE only when processing a virtual shebang, i.e. when called from maybe_handle_shebang(). For example, when wanted_ver is empty, locate_python would search the following sequence:

configured_value = get_configured_value(config_key); if (configured_value) result = find_python_by_version(configured_value); if (result == NULL) result = find_python_by_version(virtual_mode ? L"2" : L"3"); if (result == NULL) result = find_python_by_version(virtual_mode ? L"3" : L"2");

This change works for me with various combinations of enabled PythonCore registry keys, PY_PYTHON values, and shebang lines. Note that the behavior of the plain "#!python" virtual shebang gets lumped in with virtual Unix paths, but I don't know why anyone would add this shebang without a target version.

Thanks for reviewing the code for me - that does indeed look perfectly straightforward so I'm OK with following Nick's suggestion here.

As there's not been much in the way of resistance to the proposal, do people think it requires a PEP? I plan on letting this thread run its course either way, it's just a matter of whether the next step should be a tracker item or a PEP.

Thanks, Paul

I do not believe that this needs a PEP, a tracker item should be fine IMHO. We should just ensure that the original authors of the PEP are aware, as missing out their opinions would be a disservice to the Python Windows community, as small as that may be when compared to *nix. Just my £0.02p worth. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On 9 March 2016 at 21:25, Chris Angelico wrote:

On Thu, Mar 10, 2016 at 8:20 AM, Mark Lawrence wrote:

...

I do not believe that this needs a PEP, a tracker item should be fine IMHO. We should just ensure that the original authors of the PEP are aware, as missing out their opinions would be a disservice to the Python Windows community, as small as that may be when compared to *nix.

Given that this is basically a Windows-only change, it doesn't matter how large or small the Windows community is - they're the people who primarily matter :) If someone proposed a change to the way things are done on OS/2, it'd be worth getting the opinions of both of the Python OS/2 users... :P

Although it is a change to Windows-only I think it is important to think about the consistency between the way that this works on Windows compared with other operating systems. Inconsistencies here can be awkward for novices. Allow me to spell out my scenario... I teach a couple of University programming units in which students learn to program in Python, C and Java. The cohort for these units this year was 160 students. I often find myself giving the students instructions such as you can run this script I've given you with $ python myscript.py Now imagine that you've given that instruction to 160 students mostly using Windows and OSX (and a few Linux users). I find it very annoying that this could invoke Python 2 or 3 depending on the OS etc that the students are using. py.exe should solve this since I can write py -3 and then (I assume) it would lead to an error if no Python 3 version is available. However that doesn't work on OSX or Linux. Okay so maybe we should just use the shebangs. I can explain to all my students what shebangs are and instruct the OSX students to set the executable bit. Then I can say so just run $ ./myscript.py however on Windows this uses file associations which is flaky. In the past I've seen bugs where e.g. input/output redirection didn't work for scripts run in this way. It also may not work in myriad other contexts where a command line may be used. One example is from Makefiles. So when my students are working in C I can give them a Python script that will test the output of their C program and I can tell them to add this to their Makefile e.g.: test: myprog.exe ./myscript.py At this point (on Windows) various failures are possible. If make simply calls CreateProcess it fails since myscript.py isn't an exe file (I believe it also accepts .bat files but does not observe file associations). If make inspects the shebang it may come to a very different conclusion from the one that py.exe would have (e.g. that python3 does not exist since it is not on PATH). Over time I've seen this go wrong in a number of ways and have ultimately concluded that anything involving using file associations is fragile. Personally I would really like it if we could have improved consistency across OSes when it comes to invoking Python. So I would really like it if we can either have py (and maybe py3) *everywhere* or if that's not possible find some solution that does work everywhere. Can we have a single command line that guarantees to run Python 3 (or error out)? -- Oscar

On Mar 12, 2016, at 15:38, Oscar Benjamin wrote:

...

On 9 March 2016 at 21:25, Chris Angelico wrote:

...

On Thu, Mar 10, 2016 at 8:20 AM, Mark Lawrence wrote: I do not believe that this needs a PEP, a tracker item should be fine IMHO. We should just ensure that the original authors of the PEP are aware, as missing out their opinions would be a disservice to the Python Windows community, as small as that may be when compared to *nix.

Given that this is basically a Windows-only change, it doesn't matter how large or small the Windows community is - they're the people who primarily matter :) If someone proposed a change to the way things are done on OS/2, it'd be worth getting the opinions of both of the Python OS/2 users... :P

Although it is a change to Windows-only I think it is important to think about the consistency between the way that this works on Windows compared with other operating systems. Inconsistencies here can be awkward for novices. Allow me to spell out my scenario...

I teach a couple of University programming units in which students learn to program in Python, C and Java. The cohort for these units this year was 160 students. I often find myself giving the students instructions such as you can run this script I've given you with

$ python myscript.py

Now imagine that you've given that instruction to 160 students mostly using Windows and OSX (and a few Linux users). I find it very annoying that this could invoke Python 2 or 3 depending on the OS etc that the students are using. py.exe should solve this since I can write py -3 and then (I assume) it would lead to an error if no Python 3 version is available. However that doesn't work on OSX or Linux.

What if Python 3 created a symlink (or, for non-NTFS drives, a copy) of Python.exe named Python3.exe? Would that be sufficient for you to just tell your students to run: $ python3 myscript.py At any rate, this seems to be a separate issue from the one this thread is about. It's already true that py.exe is Windows-specific; no change to what it does is going to make the same command lines work on Windows and *nix. Only some new proposal (add a py command for Unix, add python2 and python3 links for Windows, make Python.exe itself a dispatcher as Apple's /usr/bin/python is on Mac, ...) is going to help you. So you might be better off creating a new thread instead of adding on to one that's mostly been resolved and a lot of people have stopped reading.

The past and future of Python (a little off topic, sorry :): Python 2: $ python myapp.py Python 3: $ py myapp.py Python 4: $ p myapp.py Python 5: $ myapp Python 6: Executing Python applications will be natively built into every OS, and the problem of a cross-platform way to conveniently distribute and run a Python *application* will be magically solved. - Koos

On 14 March 2016 at 17:18, Oscar Benjamin wrote:

I guess it's maybe just because this thread has made me realise that py.exe has changed purpose with respect to what it seemed (to me) to be before. When I was using Windows I used to always arrange for python and python3 to be available on PATH and I only used the "py" command as a way of explicitly selecting a particular non-default Python version. The idea that the default for py.exe needs to be python 3 suggests that people are now using "py" as the primary command line invocation of Python on Windows. I think is unfortunate as it takes Windows off in a different direction from every other OS. That intention wasn't the impression I had of PEP 397 at the time.

Indeed, it wasn't, and I would have always said that people should put the version of Python that they want on PATH. Indeed, I still do that. I don't think there's any "official" change in policy, nor is there a groundswell of people using py.exe to invoke Python on the command line. But PATH management remains messy and is probably even more so now that per-user installs are the default (per-user PATH entries go after system PATH entries on Windows, which makes the default behaviour complex to describe, there's no way around that). So using py.exe (which is always on PATH, and which gives access to any Python) is possibly a more attractive option nowadays. I've personally been experimenting with using it, and I've found that the "Python 2 takes priority" behaviour is suboptimal for my interactive use - this thread implies that I'm not alone in that. So I'll be following up with a change to improve that default. That's all, as far as I'm concerned. But as for "the canonical way to run Python" - much less "the canonical way to ensure you're running Python 3 (or 2)" - I don't think there's any such thing, and honestly there never has been since Python 3 came into existence and a proportion of the community needed "python" to continue referring to Python 2, even though a newer version had been released. If you (or anyone else) wanted to put together a proposal for such a cross-platform standard way of launching specific Python versions, then by all means go ahead. I can imagine it would be immensely useful to have such a thing in a teaching context. Personally it would be of no value to me, though, so I'm not going to be interested in such a proposal. I apologise if I gave the impression in this thread that there's any sort of "official" change in advice on how to launch Python. As far as I know, there hasn't been. Paul

On 15 March 2016 at 04:47, Nick Coghlan wrote:

* accessing Python 3 on *nix systems (without a tool like vex, pyenv or conda)

On the *nix side of things, the long term objective is to get "python" to a point of being usable for the latter case, but there's still a lot of other things to be done before that's a realistic option (e.g. migrating system packages over to using their own dedicated binary or symlink, so "python" can be switched to point to something else without affecting system services).

Ah, OK. I hadn't realised that was a goal for Unix. That's good to know. Paul

On Mar 15, 2016, at 04:25, Oscar Benjamin wrote:

...

On 15 March 2016 at 04:47, Nick Coghlan wrote:

On the *nix side of things, the long term objective is to get "python" to a point of being usable for the latter case, but there's still a lot of other things to be done before that's a realistic option (e.g. migrating system packages over to using their own dedicated binary or symlink, so "python" can be switched to point to something else without affecting system services).

Well that would initially improve things but what happens when python 4 comes around?

Nothing. It'll be called just "python" on both platforms. Just like when Python 2.0 came out, it was just called "python", not "python2", and was no more incompatible with 1.5 than 1.5 had been with 1.4. Python 3 was a once-in-a-lifetime, or at least once-in-a-generation, thing, not a plan to overhaul everything once/decade. (At least that's the impression I get from the PEPs, Guido's blogs, other dev's blogs, and the mailing lists.) The only way I can imagine Python 4.0 being incompatible is 3.9 is followed by 3.10 and somewhere in the distant future the memory of the 2.5->3.0 transition has faded (or the *nix environment has changed) to the point where a similar 3.14->4.0 seems like a good idea.

On 15 March 2016 at 12:01, Paul Moore wrote:

On 15 March 2016 at 11:25, Oscar Benjamin wrote:

...

AFAICT the default behaviour of the Windows installer does not add Python to PATH. Correct me if I'm wrong as I haven't used it myself for some time but when I tell my students to "install Python 3.5" and then to type "python" in the terminal a lot of the Windows users come back to me with PATH problems (specifically that python was not added to PATH).

I would have thought that is relatively easy to resolve. A pain to have to do in a classroom environment, certainly, but manageable.

It's easy enough to resolve if they bring their computer directly to me. It's less easy to resolve by email. It just becomes something many students waste time trying to fix when they're not yet ready to meaningfully learn from the experience.

The reasons Python is not added to PATH are something that has been debated over and over again on various lists. As far as I know, neither option is ideal, but "not on PATH by default" is typically seen as the least likely to fail in confusing ways.

Why would we not want python on PATH? If it's because of having multiple installed Pythons then maybe it's possible to improve the installer so that it gives the user a selection of which is on PATH and adds it by default if it isn't already there. A simple rule: "if Python is not on PATH then the installer assumes that the user wants to add it" would suffice.

You could (relatively easily) write a small Windows Scripting Host script to locate the version of Python you wanted people to use via the registry, and add it to the front of PATH. That would need elevation to work, of course, but would give a known-good starting point.

I would probably have more success telling them to tick the "add to PATH" box on the installer :) (A proportion would get it wrong whatever I say though)

On Unix, tell people just "run python3".

It's not always a question of telling people what command to run. The particular scenario that just came up is that of a C program with a Makefile and a Python script that tests the output of the C program. So I give the students a skeleton project that looks like proj-1.0.zip/ proj-1.0/ projmain.c Makefile tests/ runtests.py The idea is that they should fill in the C code to complete a program. The runtests.py script runs their program testing input/output combinations and scores how much they have completed. Now in Makefile I have test: proj.exe python tests/runtests.py So the students can run "make test" to rebuild their project and run the tests. The question is how to set this up when "python" is not guaranteed to be on PATH and could be many different versions of Python. ATM I have to exhaustively test all combinations of Python 2.7 and 3.5 and Windows, OSX and Linux and then I still hit up against problems because the way in which they've installed Python is not the same as the machines I tested on. Testing the output of a subprocess in 2/3 compatible code is painful because it comes out as bytes in 3 and str in 2. Really the only necessary incompatibility that I should need to deal with in this scenario is Windows line endings. All the others like which version of python will run, whether or not python is on PATH and the 2/3 incompatibilities are all down to Python rather than the inherent variabilities of the OSes. -- Oscar

Le 15/03/2016 14:12, Paul Moore a écrit :

On 15 March 2016 at 12:38, Oscar Benjamin wrote:

...

Why would we not want python on PATH?

You should probably go and hunt out previous discussions (your best bet is likely the python-dev archives). They were pretty extensive, and I'd likely get details wrong if I tried to summarise.

...

If it's because of having multiple installed Pythons then maybe it's possible to improve the installer so that it gives the user a selection of which is on PATH and adds it by default if it isn't already there.

Certainly it's only an issue if the user has multiple Pythons. Of course, this can include things like conda or ActiveState Python, or programs like Lilypond that bundle Python.

Some issues I recall:

1. You can improve the Python 3.6 installer, but if the user installs Python 2.7 after 3.6, they'll get the old installer with that. And conda may do something else altogether. So fixing just one installer doesn't remove the issue. 2. User installs can only add to the user part of PATH, which the OS adds *after* the system PATH. So if you do a system install and a user install, the system install will *always* take precendence, regardless of what you ask for. This is particularly problematic as Python 3.5+ defaults to a user install. 3. When you ask for a new Python to be added to PATH, should previous ones be removed? If you then uninstall the new Python, will you be left with nothing on PATH?

I've seen the view expressed that PATH is for the user to manage and installers have no business changing it at all. While I'm not sure that many people who write installers would agree with that, having dealt with my own share of messed up PATHs caused by installers, I can certainly sympathise with that position.

Paul

Yes, but you are able to deal with those issues. And they happen rarely. Failing to run Python in the terminal occurs every single introduction course I give. Every single one. And without help, a beginner will have trouble solving it because it's hard to search in Google for something you know nothing about. So some of them, the ones that can understand English and see the value of looking it up for hours, may solve it. The other ones will give up. Another problem is the gigantic time and energy wasted for this : I have to tell about this box in every course, write it down (with screenshot) in every tutorials, mention it in every videos I do. And yet, yet! People still come to me, write comments, emails, not understanding why typing "python" in this big black windows doesn't work. And then, you have the worst case scenario. The one where the person, a bit tech saavy, tried to edit the PATH manually in this tiny, unresizeable window, and messed it up. Now, try to diagnose that over skype, or on a forum, or on twitter... I already made the choice to spends hours of my life helping people with Python, but I wish I could spend it on explaining how they can make their computer do nice stuff, not on making sure they tick boxes.

On Tue, Mar 15, 2016, at 13:47, Paul Moore wrote:

Agreed. One of the issues with the debates about whether to add Python to PATH by default was that the people involved - the Python core devs - were not at all typical users (they probably have multiple Python versions installed, and they are comfortable with technical details like PATH management, etc).

I think what might be most appropriate would be to have a "Python Console" in the start menu (alongside the IDLE entry) which sources a bat file to add the correct python version (and the scripts directory for pip and easy_install) to that window's PATH, rather than installing it in the global PATH, and users can learn to start the console from that icon when they want to run python commands. Inspired by the fact that e.g. Visual Studio has something that does the same.

On 15 March 2016 at 20:58, Steve Dower wrote:

On 15Mar2016 1231, Random832 wrote:

...

I think what might be most appropriate would be to have a "Python Console" in the start menu (alongside the IDLE entry) which sources a bat file to add the correct python version (and the scripts directory for pip and easy_install) to that window's PATH, rather than installing it in the global PATH, and users can learn to start the console from that icon when they want to run python commands. Inspired by the fact that e.g. Visual Studio has something that does the same.

This is one of two solutions I'd be comfortable with.

The other is to rename "py[w].exe" as "python[w].exe".

I'm very conscious that as an experienced user, I don't actually care what the installer does, as I'll reconfigure things the way I want anyway. However, in my opinion, the worst part of having a "Python command prompt" start menu item is that it assumes everyone wants to use cmd.exe. But there's also powershell users to consider. Furthermore, having a command prompt that does what you want doesn't help people who want to run Python from something like a scheduled task. Of course, for Python it's no issue, as you can use the full path to the interpreter and that's fine - I learned my dislike of this technique from Visual Studio, where it's not that simple... I'm not sure renaming py.exe as python.exe is such a good idea either. I don't have a strong reason to give, just a suspicion that the subtly different arguments, and the fact that it (by design) doesn't respect PATH, make me concerned that it'll cause even more subtle issues than the current approach. Also, it's not possible for users with their own approaches to "opt out", where a PATH setting can be altered by the user. Anyway, as I say, I'll probably stick to doing things my own way whatever happens. Paul

On 15Mar2016 1414, Zachary Ware wrote:

On Tue, Mar 15, 2016 at 3:58 PM, Steve Dower wrote:

...

On 15Mar2016 1231, Random832 wrote:

...

I think what might be most appropriate would be to have a "Python Console" in the start menu (alongside the IDLE entry) which sources a bat file to add the correct python version (and the scripts directory for pip and easy_install) to that window's PATH, rather than installing it in the global PATH, and users can learn to start the console from that icon when they want to run python commands. Inspired by the fact that e.g. Visual Studio has something that does the same.

This is one of two solutions I'd be comfortable with.

The other is to rename "py[w].exe" as "python[w].exe".

I've wondered about allowing the launcher to determine the Python it should invoke by its own name. That is, if the launcher is named 'python3.exe' it should behave as 'py -3'; 'python2.7.exe' should behave as 'py -2.7'. I wrote a patch to that effect a year or two ago but never got it polished up enough to submit. What about doing this, and at launcher install time (or at 'repair installation' time) create links for each found Python (and python2/python3 if they exist)?

Very tough to automatically install for all found Pythons like this through an MSI, but if the not-found exit code is 9009 then there's no reason we can't just install copies for as many versions as we like. What would also be nice is "activatepyX.Y" scripts (presumably in both .cmd and .ps1 formats) that would modify the current PATH. I started a PEP a while back proposing these but never finished. If we start adding this many files I'd also want to move the launchers into their own directory (probably "C:\Program Files\Common Files\Python\Launcher") and add that to the global PATH. As long as we strictly control what files are in there, I have no problem with adding it - we just don't want any random DLL or EXE getting in there. Cheers, Steve

On Wed, Mar 16, 2016 at 8:29 AM, Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:

If this is only intended for rank beginners, what about just disabling the checkbox, with a warning, if there's already a program named "Python" anywhere on the PATH? Then, when someone gets into trouble because they're installing two Pythons, they'll get a warning and be able to ask their teacher or search StackOverflow

please no -- it should be easy and obvious to "upgrade" python -- i.e. the last one you installed is what "just works". If the default does that, then a non-defautl option to not override the existing one would be nice: """ Warning: there is an existing python installed on this system: check here if you want to continue to have the old version be used as the default. Leve the box unchecked if you want the version to be the new default. """ or something like that. After all, what do people expect when they have MSWord version X, and then install MSWord version X+1 ? They expect that when they run Word after that, they'll get the new version. Is this going to surprise anyone??? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

The uninstall problem is actually that "python" would stop working completely in that case, and it's not necessarily obvious why or how to fix it. The leave-behind problem doesn't really matter as the directory is not searched if it doesn't exist, but we also don't leave behind entries added by the installer. A user who customizes their own PATH will obviously need to manually remove the entry, but that's a manual action both times so I don't see any concern there. At one point I was trying to convince the Windows team to add a global "python" command to all Windows installs (probably 10 and later - we don't backport stuff like this, but it could be a manual install) that would act like the py.exe launcher but also automatically download Python if you didn't have it. What would people think if I got that to happen? Top-posted from my Windows Phone -----Original Message----- From: "Andrew Barnert" Sent: ‎3/‎16/‎2016 8:30 To: "Steve Dower" Cc: "python-ideas@python.org" Subject: Re: [Python-ideas] Make py.exe default to Python 3 On Mar 15, 2016, at 13:58, Steve Dower wrote:

...

On 15Mar2016 1231, Random832 wrote: I think what might be most appropriate would be to have a "Python Console" in the start menu (alongside the IDLE entry) which sources a bat file to add the correct python version (and the scripts directory for pip and easy_install) to that window's PATH, rather than installing it in the global PATH, and users can learn to start the console from that icon when they want to run python commands. Inspired by the fact that e.g. Visual Studio has something that does the same.

This is one of two solutions I'd be comfortable with.

The other is to rename "py[w].exe" as "python[w].exe".

PATH is used to resolve system DLLs and common commands. Over time, better security features are being added for core system components, but it is still possible to hijack programs this way.

But isn't the whole point here that we want novices to be able to treat python and/or python3 as a "common command", just like py? That implies either putting the executable in an existing PATH directory, or adding the executable's directory to the PATH (or, of course, renaming py, as you suggest, since that already gets put into an existing directory).

It also has a serious conflict problem once the second version of Python is installed with this option enabled, in that *anything* currently referring to just "python" will change.

If this is only intended for rank beginners, what about just disabling the checkbox, with a warning, if there's already a program named "Python" anywhere on the PATH? Then, when someone gets into trouble because they're installing two Pythons, they'll get a warning and be able to ask their teacher or search StackOverflow or whatever and get a quick answer. And that means we don't have to solve the conflict problems, the uninstall leave-behind problems, etc. for multiple pythons.

On 16 March 2016 at 18:06, Ethan Furman wrote:

On 03/16/2016 10:46 AM, Steve Dower wrote:

...

At one point I was trying to convince the Windows team to add a global "python" command to all Windows installs (probably 10 and later - we don't backport stuff like this, but it could be a manual install) that would act like the py.exe launcher but also automatically download Python if you didn't have it. What would people think if I got that to happen?

That would be awesome.

Download the latest 2.7 and the latest 3.x (installed in that order), and install py.exe.

Agreed it would be awesome. I see no reason to bother with 2.x, though. If the user knows enough to know they want 2.x they can download and install it. Otherwise just give people the latest and greatest Python. Paul

Le 16/03/2016 18:46, Steve Dower a écrit :

The uninstall problem is actually that "python" would stop working completely in that case, and it's not necessarily obvious why or how to fix it.

The leave-behind problem doesn't really matter as the directory is not searched if it doesn't exist, but we also don't leave behind entries added by the installer. A user who customizes their own PATH will obviously need to manually remove the entry, but that's a manual action both times so I don't see any concern there.

At one point I was trying to convince the Windows team to add a global "python" command to all Windows installs (probably 10 and later - we don't backport stuff like this, but it could be a manual install) that would act like the py.exe launcher but also automatically download Python if you didn't have it. What would people think if I got that to happen?

I would pay for that to happen :)

Top-posted from my Windows Phone ------------------------------------------------------------------------ From: Andrew Barnert mailto:abarnert@yahoo.com Sent: ‎3/‎16/‎2016 8:30 To: Steve Dower mailto:steve.dower@python.org Cc: python-ideas@python.org mailto:python-ideas@python.org Subject: Re: [Python-ideas] Make py.exe default to Python 3

On Mar 15, 2016, at 13:58, Steve Dower wrote:

...

...

On 15Mar2016 1231, Random832 wrote: I think what might be most appropriate would be to have a "Python Console" in the start menu (alongside the IDLE entry) which sources a bat file to add the correct python version (and the scripts directory for pip and easy_install) to that window's PATH, rather than installing it in the global PATH, and users can learn to start the console from that icon when they want to run python commands. Inspired by the fact that e.g. Visual Studio has something that does the same.

This is one of two solutions I'd be comfortable with.

The other is to rename "py[w].exe" as "python[w].exe".

PATH is used to resolve system DLLs and common commands. Over time,

better security features are being added for core system components, but it is still possible to hijack programs this way.

But isn't the whole point here that we want novices to be able to treat python and/or python3 as a "common command", just like py?

That implies either putting the executable in an existing PATH directory, or adding the executable's directory to the PATH (or, of course, renaming py, as you suggest, since that already gets put into an existing directory).

...

It also has a serious conflict problem once the second version of Python is installed with this option enabled, in that *anything* currently referring to just "python" will change.

If this is only intended for rank beginners, what about just disabling the checkbox, with a warning, if there's already a program named "Python" anywhere on the PATH? Then, when someone gets into trouble because they're installing two Pythons, they'll get a warning and be able to ask their teacher or search StackOverflow or whatever and get a quick answer. And that means we don't have to solve the conflict problems, the uninstall leave-behind problems, etc. for multiple pythons.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Mar 15, 2016 at 9:59 PM, Chris Barker - NOAA Federal wrote:

The reality is that MS has not updated the GUI for setting PATH since Windows 3.1 as far as I can tell. It sucks.

Actually, Windows 10 (or at least Windows 10 with the latest updates) introduced a much, MUCH nicer interface for PATH editing. Here's a screenshot: http://snag.gy/WH4Oj.jpg With this interface, one can edit individual entries (an edit to the Python 2.7 \Scripts folder in the system PATH is in progress in this screenshot), use the browse button to select new folders via GUI, tweak the order of the list, easily remove entries, and so forth. The details of the plaintext version of PATH that one would use at the command prompt are hidden behind the "edit text" button. I recently performed a massive cleanup to my PATHs after discovered this new interface, and it was really easy.

...

Actually, Windows 10 (or at least Windows 10 with the latest updates) introduced a much, MUCH nicer interface for PATH editing.

Here's a screenshot: http://snag.gy/WH4Oj.jpg

Finally! and after only 20 years. Great to see that. But we will be dealing with pre Windows10 for a a good long time :-) Plus fixing a way to fix a problem is, while improving the situation,

probably not the best way to look at the situation.

well, it does change teh burden teh choice is between auto-setting PATH, and requiring people to set/adjust it themselves -- each has it's advantages. And how easy it is to adjsut it yourself does effect the trade-off. But as we will be supporting Windows pre-10 for a long time, we still need it to "just work" for less sophisticated users without them having to mess with PATH. As in: If someone installs a version of python with defaults, they should then get that version when they type "python" (or maybe "py") at the command line. If they want something other than the last one they installed, then they'll have to mess with PATH or other configuration... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

Paul Moore writes:

On 16 March 2016 at 17:17, Chris Barker wrote:

...

If someone installs a version of python with defaults, they should then get that version when they type "python" (or maybe "py") at the command line.

If they want something other than the last one they installed, then they'll have to mess with PATH or other configuration...

In theory, this makes sense to me.

Really? To me, it never made a lot of sense even in theory. It's most likely to totally screw exactly the users it's addressed to (the ones who don't know how, don't wanna know how, and probably shouldn't be allowed[1], to manipulate PATH). It seems to me that the situation is 1. Power users and developers are often using a new Python in a "trial" situation or otherwise not wanting an *installed* Python on PATH. For historical reasons, they are used to solving that by not putting it on PATH by default. This weighed large in earlier discussions for the reasons you (Paul) give. As you also acknowledge, that large weight (vs. educators' needs) is hardly considered desirable by anybody, but the educator faction (often well-represented by folks like Raymond Hettinger and David Beazley) either didn't weigh in or didn't object or in the end conceded their objections were weak/had no good solution. 2. Python tries to provide both strong guarantees of backward compatibility without inhibiting development. This resulted in a kind of "punctuated equilibrium" evolution where x.y was theoretically backward-compatible with x.y-1, but that's never been quite true (bugs, *very* occasional changes of syntax as compared to the size of the language, errors that are caught and handled differently from the new version extension's definition, etc). Surprising users with *intermittent* and *hard to diagnose* bugs in other applications has never been considered acceptable, and the *nix distros I'm most familiar with (MacPorts, Debian, Gentoo) all provide a "python-select" utility for explicit choice of binding of "python", "python2", and "python3" to executables, with a user decision required to change the current bindings. This suggests to me that there are excellent reasons based in experience against defaulting to "upgrading" Python. "Sufficiently naive users" are just as vulnerable to such surprises, and as an educator myself, I would be unlikely to want to take responsibility for some other teacher's software being broken by my suggestion to upgrade Python so that *my* software can use newer syntax. I'd rather deal with my own problems by teaching students to deal with PATH (but see fn [2]). 3. In a previous geological epoch, naive beginner users used to be used to fixing up PATH, but that gave way in the early days of the current epoch to "computers for the rest of us (and big margins for Apple and Microsoft)" and "DLL hell", which by and large has been remedied by app-ization (ie, including all the DLLs you need, providing resources in a fixed hierarchy relative to the executable, and hard-coding those relative paths into the executable). This is how Microsoft and Apple arrange to ensure that only one instance of an app need to be installed, and resulted in such inelegant devices as "fat binaries" and the Microsoft Word format menu for saving. Unfortunately, this flat-out contradicts the Unix philosophy of modularized tools that do only one thing, and in the case of hosts involved in applications that face the Doomsday Machine usually called "the Internet", it's essential that certain services (crypto, authn, authz, ...) and important that others (anything with an overflowable buffer, which is everything) be upgraded in one place asap, rather than discarding the whole system in order to upgrade all apps that might be exposed. CPython chose to *not* distribute itself as app-ized by default, and in fact, doesn't do that at all, leaving it up to 3rd parties. I don't really see how to do that, anyway, given the huge amount of useful software that expects a previously-installed Python. Anyway, AFAIK that corner of the ecosystem is actually well-populated (Active State, Anaconda, etc). Why isn't one of those the appropriate solution to this problem for educators?[2]

...

After all, what do people expect when they have MSWord version X, and then install MSWord version X+1

But nobody *ever* runs multiple versions of MS Word.

Slightly off the mark, I think. The reason analogies to Word or Excel implode is that they suck as general-purpose programming environments (IMHO) and so rarely depend on third-party modules.[3] People write programs "strictly from need" (they're actually manipulating Word files), or because it's the only hammer they've got (accountants writing financial models in Excel), or backward-compatibility with programs written by one-hammer developers (financial models in Excel). And the language-level backward-compatibility burden is entirely borne by Microsoft -- which they are quite good at AFAICT, and that (expensive!) backward-compatibility is why "nobody [aka "Andrew Barnert"<wink/>] *ever*[sic] runs multiple versions of Word." Footnotes: [1] http://linux-mafia.com/~rick/faq/crybaby.html#allowed [2] Personally, the great majority of my students use Macs and at least on Macs the PSF-installed IDLE provides a nice icon in Applications, and that's how they get started, and even those who fall into the "shouldn't be allowed" group have little trouble handling Python 2 and Python 3 on the same box. So I don't even bother with those, although I'm currently reviewing Anaconda as a better solution for statistical applications. [3] Counter-examples welcome, I recognize my limited experience here.

On 17 March 2016 at 09:14, Paul Moore wrote:

On 17 March 2016 at 08:10, Stephen J. Turnbull wrote:

...

...

...

If someone installs a version of python with defaults, they should then get that version when they type "python" (or maybe "py") at the command line.

If they want something other than the last one they installed, then they'll have to mess with PATH or other configuration...

In theory, this makes sense to me.

Really? To me, it never made a lot of sense even in theory. It's most likely to totally screw exactly the users it's addressed to (the ones who don't know how, don't wanna know how, and probably shouldn't be allowed[1], to manipulate PATH).

Hmm, I think I follow what you're getting at.

It does seem reasonable to me that if a user installs (a version of) Python, then they should find that the "python" command works and executes that version.

Great! I'm glad that we're agreed on the basic point that: Python is installed in standard way implies -> "python" command works in all the usual places

Particularly so now that a default install of Python 3.5 on Windows puts the executables in a relatively hard to locate directory (so manually adding to PATH is tedious). Replace the "python" command with "py" in this statement and we have the current behaviour of the Python installer.

I'm OK with conceding that anyone installing a second version of Python counts as an "advanced" user and should manage the results themselves :-) (Exception: if you uninstall your current version first, you're back to the "new install" case).

So for new users (without Python install): "Install your preferred copy of Python, and use the command py to run Python (either to run a script, or for interactive use)".

What? I thought we just agreed it should be "python"! :) This brings us full circle back to the reason I interjected in this thread: why are we making the standard invocation of Python different on Windows? I'll drag up a bit of conversation from earlier: On 15 March 2016 at 04:47, Nick Coghlan wrote:

On 15 March 2016 at 09:01, Paul Moore wrote:

...

I apologise if I gave the impression in this thread that there's any sort of "official" change in advice on how to launch Python. As far as I know, there hasn't been.

It's still "python" - that works regardless of version on Windows (with a suitably configured PATH), in virtual environments and in pyenv and conda environments (and probably in Enthought Canopy as well, but I haven't checked that).

(and it's also "python" on every other non-Windows OS I've used, leaving aside "python3") So are we agreed or not that "python" is the way to run... Python?

I'm also inclined to assume that for the *really* "new to IT" users, Idle (which is available as a start menu item) is a better starting point anyway.

My own students are introduced via Idle and have no problem (on Windows or OSX) locating Idle graphically. It's later on when we expect them to use the command line they discover that they have PATH problems. But this is happening at the first point that they use the terminal (it seems natural since they've learned Python already that it should be one of the first terminal commands they would use). The installer already has the capability and a tickbox for this. See here: https://docs.python.org/3.5/using/windows.html The tickbox that says: "Install launcher for all users (recommended)" is ticked already and describes itself as being "recommended". The one that says "Add Python 3.5 to PATH" is unticked and apparently not "recommended". If we're agreed that the "python" command should work once Python is installed then why are we not "recommending" that people tick the box that does this? Advanced users should understand what this means and can decide for themselves whether or not they want to tick/untick this box so I don't see why they're relevant on the issue of what is default and what is recommended. Novices won't understand what the text means so we really need to think about them when choosing a default behaviour here. How about a UI that shows the user what Pythons are installed and allows them to select which one is on PATH? Another option would be to add a path configuration menu to Idle. This way a user can open Idle, go to something like settings->PATH configuration and then be presented with a list of installed Pythons and the ability to select which should be on PATH. That would be better than asking novices to go edit PATH but it still begs the question: if this is part of the standard setup then why is not standard to do it when installing? -- Oscar

On Mar 17, 2016, at 01:10, Stephen J. Turnbull wrote:

And the language-level backward-compatibility burden is entirely borne by Microsoft -- which they are quite good at AFAICT, and that (expensive!) backward-compatibility is why "nobody [aka "Andrew Barnert"<wink/>] *ever*[sic] runs multiple versions of Word."

I wasn't running Word 2003 and Word 2007 as VBA development platforms, or using them side by side because I wanted both.[1] That's just what the installer decided to do.[2] Most people don't notice this, because how many users launch Word from the command line or via Win-R?[3] Not to mention that most people don't keep upgrading the same Windows box continuously over Office's 4-year dev cycle;[4] they're either still running 2003, or they threw that laptop away long ago. At any rate, the point is that Word is a terrible example of "everybody expects side-by-side installs but the latest-installed version wins"--most people don't expect side-by-side installs, and when you do get them, the latest version installed doesn't win (and, even if it did, they wouldn't notice). That doesn't necessarily mean it would be the wrong decision for Python, just that the argument "everyone else does it" doesn't help, because it's not true. If we want to talk about language-level compatibility, Visual Studio might be a better example than Office. And, as mentioned earlier in the thread, Visual Studio solves this problem by putting a "switching script" on the PATH, which adds the selected copy's executables to the PATH when run (and by adding special start menu shortcuts to open a new command prompt with the PATH set up). So, CL.EXE doesn't come from the latest MSVS installed either. [1]: In fact, the only reason I needed Word 2007 in the first place was that i contracted for a company that insisted I have it, even though every document they sent me worked just fine in OpenOffice... [2]: This is just a guess, but I'd bet it's because the $100 Office Home Professional 2007 didn't include the same subset of apps as the $100 Office Personal Business 2003 it replaced, and they didn't want people complaining about the upgrade taking away their PowerPoint or Access or Publisher or whatever the way people complained during the 2000-2003 upgrade. You'd think they could solve that by just offering the same set of packages of apps under consistent names and price points so this never came up, and I'll bet every 4 years, the suite-integration dev team for Office thinks they've convinced management that's a good idea, and then 3 months before release they discover that marketing convinced PM otherwise, and they now have to deal with it. [3]: People _do_ launch it via Win search for "word" nowadays, but that uses Windows' clever search guessing and learning, not anything configurable by the installer or the user, unlike Win-R "winword". [4]: Or, if they do, either it's an IT-managed upgrade, or they're installing a pirated copy of the full Office suite (which probably has a custom installer?).

On 18 March 2016 at 20:35, Chris Barker wrote:

...

In theory, this makes sense to me. What it needs is someone to champion it.

Isn't that what this conversation is doing? :-)

Not really. By "champion" I mean "take the lead" - i.e., pull together all the arguments, summarise them, produce a proposal, write a patch (or get someone else to write it) create the tracker item, get a core dev to support it and shepherd it through to being committed. At the moment, all we're doing is discussing possibilities, nobody's stepped up to take the lead. I get the feeling that some participants in the discussion might think that discussion is enough, but I've seen too many of these threads fizzle out because no-one is interested enough, or has enough time, to do the hard bits. I just wanted to be clear that I started this thread for a *different* proposal, which came to a conclusion that I plan (other commitments permitting) to get implemented. But I'm *not* sufficiently interested in this new proposal to take it forward, so someone else will need to step up at some point if the idea is to go anywhere. Paul

On 15 March 2016 at 21:25, Oscar Benjamin wrote:

On 15 March 2016 at 04:47, Nick Coghlan wrote:

...

* Windows without a properly configured PATH (and without a tool like vex or conda)

AFAICT the default behaviour of the Windows installer does not add Python to PATH. Correct me if I'm wrong as I haven't used it myself for some time but when I tell my students to "install Python 3.5" and then to type "python" in the terminal a lot of the Windows users come back to me with PATH problems (specifically that python was not added to PATH).

Yeah, it's unfortunately currently still off by default. Since it's sysadmins that don't like it being on by default, and they're better equipped to change it back than Windows users being introduced to the command line for the first time, I'd prefer to see that particular default flipped to be opt-out rather than opt-in. Educators are the folks best positioned to argue for that change, since you're the ones that have to deal with the fallout of beginners installing Python by clicking through the installer prompts without realising they need to request the automatic PATH modification.

...

* accessing Python 3 on *nix systems (without a tool like vex, pyenv or conda)

On the *nix side of things, the long term objective is to get "python" to a point of being usable for the latter case, but there's still a lot of other things to be done before that's a realistic option (e.g. migrating system packages over to using their own dedicated binary or symlink, so "python" can be switched to point to something else without affecting system services).

Well that would initially improve things but what happens when python 4 comes around? Really I think that for something like this having major-versioned executables is a good idea. It's just a shame that it wasn't done consistently.

The major & minor versioned executables exist on *nix if people want to use them, but tend to make scripts and instructions more platform specific than they need to be. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia