Make py.exe default to Python 3 when used interactively

[pfmoore]

BPO	27064
Nosy	@terryjreedy, @pfmoore, @tjguk, @ned-deily, @zware, @zooba
Files	launcher.diff: Superseded by launcher2.diff launcher2.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/pfmoore'
closed_at = <Date 2016-05-22.18:14:54.226>
created_at = <Date 2016-05-19.21:36:05.491>
labels = ['type-bug', 'OS-windows']
title = 'Make py.exe default to Python 3 when used interactively'
updated_at = <Date 2016-05-22.18:15:34.315>
user = 'https://github.com/pfmoore'

bugs.python.org fields:

activity = <Date 2016-05-22.18:15:34.315>
actor = 'zach.ware'
assignee = 'paul.moore'
closed = True
closed_date = <Date 2016-05-22.18:14:54.226>
closer = 'paul.moore'
components = ['Windows']
creation = <Date 2016-05-19.21:36:05.491>
creator = 'paul.moore'
dependencies = []
files = ['42906', '42918']
hgrepos = []
issue_num = 27064
keywords = ['patch', 'needs review']
message_count = 13.0
messages = ['265898', '265899', '265912', '265948', '265949', '265956', '265961', '265964', '265971', '265999', '266009', '266019', '266069']
nosy_count = 7.0
nosy_names = ['terry.reedy', 'paul.moore', 'tim.golden', 'ned.deily', 'python-dev', 'zach.ware', 'steve.dower']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue27064'
versions = ['Python 3.6']

[pfmoore]

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 https://mail.python.org/pipermail/python-ideas/2016-March/038667.html. My summary of the consensus was at https://mail.python.org/pipermail/python-ideas/2016-March/038759.html

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.

[zooba]

LGTM.

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.

[pfmoore]

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.

[zooba]

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?

[pfmoore]

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.

[ned-deily]

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.

[pfmoore]

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.

[zware]

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.

[terryjreedy]

+1 By 'interactive use', I presume you mean at console command line
path\to\somewhere>py...

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.

[pfmoore]

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.

[zooba]

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.

[pfmoore]

OK, no problem. Like you say, not a high priority.