Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make py.exe default to Python 3 when used interactively #71251

Closed
pfmoore opened this issue May 19, 2016 · 13 comments
Closed

Make py.exe default to Python 3 when used interactively #71251

pfmoore opened this issue May 19, 2016 · 13 comments
Assignees
@pfmoore
Labels
OS-windows type-bug An unexpected behavior, bug, or error

Comments

@pfmoore
Copy link
Member

pfmoore commented May 19, 2016

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
    Copy link
    Member Author

    pfmoore commented 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:

    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.

    @pfmoore pfmoore self-assigned this May 19, 2016
    @pfmoore pfmoore added OS-windows type-bug An unexpected behavior, bug, or error labels May 19, 2016
    @zooba
    Copy link
    Member

    zooba commented 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:

    • 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
    Copy link
    Member Author

    pfmoore commented 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
    Copy link
    Member

    zooba commented 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
    Copy link
    Member Author

    pfmoore commented 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
    Copy link
    Member

    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
    Copy link
    Member Author

    pfmoore commented 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:

    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
    Copy link
    Member

    zware commented 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
    Copy link
    Member

    +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
    Copy link
    Member Author

    pfmoore commented 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
    Copy link
    Member

    zooba commented 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
    Copy link
    Member Author

    pfmoore commented May 21, 2016

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

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented 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

    @pfmoore pfmoore closed this as completed May 22, 2016
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @pfmoore pfmoore

    Labels
    OS-windows type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    5 participants
    @pfmoore @zooba @ned-deily @zware @terryjreedy