The python command is still not available out-of-the box on macOS, so it didn't completely live up to the expectation of being the cross-platform way to launch 2/3 source compatile scripts.

Did you mean python2 there? In my experience macOS comes with python installed (and invoking Python 2) but no python2 link (hard or soft). In any case I'm not sure how this strengthens your argument.

I'm also still unhappy with any kind of endorsement of python pointing to python3. When a user gets bitten by this they should receive an apology from whoever changed that link, not a haughty "the PEP endorses this".

Regardless of what macOS does I think I would be happier in a future where python doesn't exist and one always has to specify python2 or python3. Quite possibly there will be an age where Python 2, 3 and 4 all overlap, and EIBTI.

I'm also still unhappy with any kind of endorsement of python pointing to python3. When a user gets bitten by this they should receive an apology from whoever changed that link, not a haughty "the PEP endorses this".

And are you more happy with the current state where /usr/bin/python pointing to python2 effectively endorses that? I am afraid we are doomed to endorse something whatever we do,.

Regardless of what macOS does I think I would be happier in a future where python doesn't exist and one always has to specify python2 or python3. Quite possibly there will be an age where Python 2, 3 and 4 all overlap, and EIBTI.

Given python2 dies in less than two years, I am afraid that future of yourse will be really really short ;).

(still not yet speaking as the SUSE Python maintainer, but I expect to get there on May 2nd ;))

The endorsement of "python" -> "python2" exists regardless of what you put in a PEP.

You are hopelessly naive expecting that use of Python 2 will die at the time support is stopped. In fact IIRC Red Hat was at some point expecting to make money supporting it past that deadline (not sure if that's still their expectation).

You are hopelessly naive expecting that use of Python 2 will die at the time support is stopped. In fact IIRC Red Hat was at some point expecting to make money supporting it past that deadline (not sure if that's still their expectation).

No, I'm not expecting that.
However, I am expecting that to actually make Python 2 go away, (so that Red Hat doesn't have to support it anymore, and I can spend my time on better things), I need to actively discourage its use.
As long as things keep working smoothly, some people won't switch to Python 3 – and at some point things need to stop working smoothly. I want to avoid that being a world-breaking event. I want to move to a state where only things that actually need Python 2 use Python 2, so we can identify them and help port them.

FWIW Homebrew does include a python2 -> python symlink, so e.g. if you're installing 2.7.14 from brew, /usr/local/bin/python2 works as expected.

Yes, Homebrew found out the hard way that PEP 394 is actually relatively well thought-out and should be followed.

Forget about whatever Apple does - that shouldn't influence our decision here. Apple's out of the box distribution of open source tools isn't a model of modernity or utility. It's only whatever works for them. Homebrew (what I use) and maybe Fink or MacPorts (distributions I no longer use) are probably more receptive to whatever we decide.

I know for a fact that Debian/Ubuntu won't do anything about /usr/bin/python until at least after 2.7 is EOL'd. I'm also not sure that any change to the PEP will sway them even after that. It's even been difficult to get consensus on adding a python2 symlink and shebanging all CLIs with that.

Having said all that, I think it does make sense to allow distributions to make PEP-aligned policy as they see fit. They know their communities, policies, implications, etc. better than "we" do. OTOH, I'm also happy waiting until 2.7 EOL to make any changes to this PEP's policy. (Maybe we can say, here's where the PEP stands post-2020).

To be clear, what I would endorse is a world where python simply doesn't exist for most users. That seems compatible with what Fedora is striving for. I don't have any contacts inside Apple any more, so we'll have to exclude macOS.

I haven't memorized PEP 394 -- if it currently stipulates that python must exist we should definitely drop that requirement. But we shouldn't replace it with any kind of endorsement of people making python point to python3.

(I do think venv is wrong too, but it's too late, and perhaps it's the compromise we're all looking for.)

Also, the PEP currently explicitly says:

It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2.

You are hopelessly naive expecting that use of Python 2 will die at the time support is stopped. In fact IIRC Red Hat was at some point expecting to make money supporting it past that deadline (not sure if that's still their expectation).

I will let others argue over this, they seem to be smarter than me, but just let me note here that so far I am an employee of Red Hat, so I know something about the support of EOL'ed programs.

FWIW Homebrew does include a python2 -> python symlink, so e.g. if you're installing 2.7.14 from brew, /usr/local/bin/python2 works as expected.

As is the case for the Python 2.7.x's provided by python.org macOS installers. And the MacPorts Python 2.7.x.

Unfortunately, Apple support of Python in macOS releases has languished (for example, no Python 3, not up-to-date 2.7, no pip, no python2 link, seriously buggy outdated Tk, deficient SSL support) to the point that it is generally a disservice to users to recommend using it. So I don't think the Apple-supplied system Python should be a factor in discussions here, other than the fact that it does provide /usr/bin/python and /usr/bin/python2.7 links that most-third party macOS Python distributors shadow by $PATH manipulation (and will continue to need to do so as least as long as Apple keeps supplying them in /usr/bin).

Maybe the python command should just print "Did you mean python2 or python3?" to stderr and fail?

That tends to confuse tools like buildsystems which detect presence of the python command. I'm not saying they should be doing that, just that a failing command is quite different from the command not being available.

@encukou Let me know when you feel this is ready to commit. Please remind me to change commit topic line to match what you put in the PR. :-)

This PEP was written a while back, so good to be revisiting.

But I also think we need to acknowledge common practice -- I doubt we will ever get to the day when there is no "python" command, and I have no idea what the numbers are, but there are certainly folks out there that are symlinking "python" to "python3" right now -- it's part of the "python 3 IS python now" approach.

So maybe the paragraph about the anticipated future where python points to Python 3 shouldn't be removed, but rather edited -- I suspect that will happen in some environments regardless of what this PEP says.

No, I really want that paragraph deleted. My point is that the PEP should not encourage hopes in that direction or endorse actions by rogue sysadmins (or distros :-), other than the established practice in virtual environments.

I want people who write 3rd party documentation to be quite aware of the repercussions when they suggest their readers type python at their shell: depending on a number of factors it may fail or invoke Python 2 or Python 3.

And I want sysadmins (and even users and distros) who "helpfully" link python to python3 be aware that this breaks Python 2 scripts that use #!/usr/bin/env python -- it doesn't just affect what the user gets when they type python at their shell.

@warsaw @kerrickstaley This version looks good to me, and I'm the only one that's commented on @encukou's python-dev thread so far, so unless one of you raises any objections, I'm going to suggest that Petr add himself as a co-author, and then we merge the update.

Right, the author credit here wouldn't just be about these particular updates - it's also about Petr being one of the primary drivers of how Fedora is handling the migration, so he is one of the folks having to stand by the recommendations it provides.

(I agree it can be a separate question, it just occurred to me to ask it while writing my earlier comment)

@ncoghlan Sorry, just been too busy to dive deeply into this, but I have lured on thread and this PR. JFDI! (And I'm find with adding @encukou as an author.)

The one "future" point I wholeheartedly agree with is that if we ever do a Python 4, I do not want to add /usr/bin/python4. I think by that time we probably can just reclaim /usr/bin/python because Python 2 will be long buried and there won't be anything backward incompatible about it (i.e. it'll just be a "normal" upgrade with the added bonus of a major version bump). That's of course if we don't move to a calver style versioning scheme <wink>.

I don't feel that great about taking new long-term responsibilities, but discussions on this PEP are probably something I'll get involved in anyway. Since the other authors don't object, let's make it explicit.

Thanks for working through this @encukou, and @gvanrossum for the initial review (I get the impression the original PR looked quite different from the final version I reviewed!)