Repository navigation
Make py.exe default to Python 3 when used interactively #71251
Description
| BPO | 27064 |
|---|---|
| Nosy | @terryjreedy, @pfmoore, @tjguk, @ned-deily, @zware, @zooba |
| Files |
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']
Activity
pfmoore commentedon May 19, 2016
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:
installed on the machine, without special-casing a preference for
Python 2.
current behaviour (for compatibility with Unix).
launcher via the ini file or environment variables, no change to
current behaviour.
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 commentedon May 19, 2016
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:
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 commentedon May 20, 2016
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 commentedon May 20, 2016
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 commentedon May 20, 2016
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 commentedon May 20, 2016
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 commentedon May 20, 2016
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:
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 commentedon May 20, 2016
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 commentedon May 20, 2016
+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 commentedon May 21, 2016
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 commentedon May 21, 2016
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 commentedon May 21, 2016
OK, no problem. Like you say, not a high priority.
python-dev commentedon May 22, 2016
New changeset 26c1e3dab624 by Paul Moore in branch 'default':
Issue bpo-27064: The py.exe launcher now defaults to Python 3.
https://hg.python.org/cpython/rev/26c1e3dab624