Title: Make py.exe default to Python 3 when used interactively
Type: behavior Stage: resolved
Components: Windows Versions: Python 3.6
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: paul.moore Nosy List: ned.deily, paul.moore, python-dev, steve.dower, terry.reedy, tim.golden, zach.ware
Priority: normal Keywords: needs review, patch

Created on 2016-05-19 21:36 by paul.moore, last changed 2016-05-22 18:15 by zach.ware. This issue is now closed.

File name Uploaded Description Edit
launcher.diff paul.moore, 2016-05-19 21:36 Superseded by launcher2.diff review
launcher2.diff paul.moore, 2016-05-20 20:55
Messages (13)
msg265898 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2016-05-19 21:36
By default, the launcher tries to launch (the latest version of) Python 2 on the user's machine. This can be altered with the configuration file, and if the user doesn't have Python 2 installed Python 3 will be used. Now that we are at Python 3.6, it's about time to change that default to try Python 3 first.

This was discussed on python-ideas in the thread starting at My summary of the consensus was at

The key points were:

1. For interactive use, make py.exe launch the latest version
installed on the machine, without special-casing a preference for
Python 2.
2. For shebang lines where an unversioned name is used, retain the
current behaviour (for compatibility with Unix).
3. When the user explicitly chooses a version, or has configured the
launcher via the ini file or environment variables, no change to
current behaviour.
4. The change is small enough that it doesn't need a PEP.

The attached patch implements this behaviour.

I assume the patch is to be applied only to Python 3.6, as it is changed behaviour, not a bug fix.
msg265899 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-05-19 22:16

The launcher is in a bit of a funny place wrt versioning, as it is now somewhat independent from the Python version it is installed with:

* won't be downgraded by 3.5 (3.4 will still stomp over the file itself)
* has a separate entry in Programs & Features
* won't be uninstalled by the regular Python installer
* (theoretically can be installed separately, but since we don't link to the MSI... ;) )
* this includes alpha/beta releases of 3.6

So I wouldn't have an issue with this going into 3.5, in the same way that we will update the bundled setuptools/pip in minor releases, but since we don't have an official OK for that just putting it into 3.6 is fine.
msg265912 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2016-05-20 07:58
Thanks Steve. I wasn't sure over versioning, which is why I decided to be conservative. Also, it's probably not good to change the default behaviour on people when they just install a patch release of 3.5.
msg265948 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-05-20 16:48
It'll change their default behavior if they get an alpha release of 3.6 though, and uninstalling the alpha won't revert it.

That said, I don't really feel like the launcher is an "alpha" product, even if the core Python engine is in that state. Possibly the RM has an opinion here?
msg265949 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2016-05-20 17:28
Because of the nature of the launcher, there's not much we can do about that IMO. And there was no real objection to changing the default on the python-ideas thread (at least for interactive use).

But I'll wait to see if Ned has anything to add.
msg265956 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-05-20 19:33
I don't have a strong opinion one way on the matter since I don't have any experience with the launcher.  I think I understand the issue of the Windows installer providing "release-independent" components (and, FTR, the OS X installer has a somewhat similar issue although the launcher there is believed to not be used much at all).  Whether we should change the defaults for future releases of 2.7.x and/or 3.5.x is probably ultimately up to the 2.7 and 3.6 release managers though I expect they would go along with whatever you all recommend.  If it does make sense to modify py.exe for 2.7.x and 3.5.x, then perhaps the corresponding change for 3.6 could be deferred until after 2.7.11 and 3.5.2 are released, which should be before 3.6.0a3, and all have consistent documentation of the changed behavior?  It's not perfect but at least all of the most recent binary releases would be consistent.

A somewhat unrelated comment on the patch:  will it be clear to users what is meant by "latest version installed"?  That is, what is meant by "latest version" in each of these cases: (scenario 1) install 2.7. then 3.5, then 3.6'; (scenario 2) install 3.5, 3.6, then 2.7; (scenario 3) install 3.6, 3.5, then 2.7; (scenario 4) install 3.6, 2.7, then 3.5.
msg265961 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2016-05-20 20:55
Thanks Ned. Personally, I'm still inclined *not* to add this to 2.7/3.5. People will get it when the install the 3.6 alphas, sure, but that seems to me to be a relatively obvious consequence of installing an alpha that includes a component that's used for all Python versions installed.

It seems to me that there will be the following categories of people:

1. No Python installed - this will just do the right thing (as would the old version).
2. Only 3.x installed - same as above.
3. Only 2.x installed - having the newly installed 3.6 become the default for the launcher seems like the expected behaviour.
4. Both 2.x and 3.x installed, and no py.ini setting the default - currently 2.x will be the default, and it will switch to 3.6. This is basically the point of the change. And it's an easy fix to add a py.ini reverting the default to 2.x.

People with a default set up in py.ini will be totally unaffected regardless.

To clarify things further for users in category (4), I've added a Misc/NEWS entry (which I should have done anyway) and an entry for "What's new".

As for the documentation using the term "latest Python version", I see what you're getting at, but I couldn't think of a better way of putting it without making the whole thing too convoluted for what is, after all, a pretty simple feature. (It's actually the *old* behaviour that's more complicated to describe). I'm happy to change it if someone can suggest a better wording, though.
msg265964 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2016-05-20 21:27
I'm very much +1 on the patch.

A couple thoughts:
- Note that 2.7 doesn't come with a launcher.

- As I understand it, the 3.5+ installer won't overwrite a newer launcher than what it would install, but the 3.4- installer will.  So the only really confusing (to my mind) thing that could happen would be someone installing 3.4 after 2.7 and 3.6, and the newly installed old 3.4 launcher reverts to defaulting to 2.x.  There's not much we can do about that, though: there will be no more 3.3 or 3.4 installers, so an update to the launcher in those branches would never see the light of day anyway.  I think this is an uncommon-enough situation that it can be ignored, but one possible way to work around it would be to install a pro-3 py.ini along with the launcher in 3.6+ (if it wouldn't be overwriting an existing py.ini).  Probably more effort than it's worth, though.
msg265971 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-20 22:41
+1 By 'interactive use', I presume you mean at console command line

When I installed 3.4.4, I wondered if it would overwrite py with older version.  Great that 3.5.x does not.  I think each installer should have latest version of py.exe.  Really great if it could detect what version of py.exe is present, if any, and adjust option accordingly.
msg265999 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2016-05-21 12:32
Terry: Correct.

As 3.4 is in security fix mode, and 2.7 doesn't come with the launcher (which I hadn't realised - thanks for pointing this out Zach!) the only real backport candidate is 3.5, so I definitely don't think it's worth backporting just for that.

Maybe it would be worth making a link available to the latest version of the installer, though, for people who want to upgrade. What do you think, Steve? From what you said I get the impression it's already there, just needs adding to the download page.
msg266009 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-05-21 16:38
Unfortunately, the current MSI for the launcher doesn't have a great interface when used separately from the main installer. It happens to be more functional than the rest (i.e. double-clicking it will give you a very quick per-user install, whereas the other MSIs that make up the installer will fail), but it's not at a point where I'd be comfortable to link directly to it.

Could I get it there? Absolutely. Not a real high priority though - there are some weird upgrade/modify edge cases that I'd rather figure out first.
msg266019 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2016-05-21 19:59
OK, no problem. Like you say, not a high priority.
msg266069 - (view) Author: Roundup Robot (python-dev) Date: 2016-05-22 11:35
New changeset 26c1e3dab624 by Paul Moore in branch 'default':
Issue #27064: The py.exe launcher now defaults to Python 3.
Date User Action Args
2016-05-22 18:15:34zach.waresetstage: patch review -> resolved
2016-05-22 18:14:54paul.mooresetstatus: open -> closed
resolution: fixed
2016-05-22 11:35:01python-devsetnosy: + python-dev
messages: + msg266069
2016-05-21 19:59:40paul.mooresetmessages: + msg266019
2016-05-21 16:38:23steve.dowersetmessages: + msg266009
2016-05-21 12:32:03paul.mooresetmessages: + msg265999
2016-05-20 22:41:10terry.reedysetnosy: + terry.reedy
messages: + msg265971
2016-05-20 21:27:25zach.waresetmessages: + msg265964
2016-05-20 20:55:55paul.mooresetfiles: + launcher2.diff

messages: + msg265961
2016-05-20 19:33:43ned.deilysetmessages: + msg265956
2016-05-20 17:28:24paul.mooresetmessages: + msg265949
2016-05-20 16:48:02steve.dowersetnosy: + ned.deily
messages: + msg265948
2016-05-20 07:58:42paul.mooresetmessages: + msg265912
2016-05-19 22:16:17steve.dowersetmessages: + msg265899
2016-05-19 21:36:05paul.moorecreate