GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — [WIP] PEP 394: Allow not installing unversioned "python" command by encukou · Pull Request #893 · python/peps

Conversation

@encukou

@encukou encukou commented Feb 13, 2019 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Member

The intended future for the python command is:

python doesn't exist and one always has to specify python2 or python3.

( – Guido, #630 (comment) )

There are three conflicting ideas around the python command, longer-term:

  1. The python command should continue to refer to Python 2 (if Python 2 is available).
  2. python is a correct shebang for py2/py3 source-compatible scripts.
  3. Python 2 should not be available (by default / after 2020).

One of these has to give.
It seems that (2) is the easiest to shed, so this proposal does just that.

  • Make python3 the preferred shebang for py2/py3 compatible scripts, as that's the only shebang that'll work on py2-less systems. (An exception is made for scripts targetting the system Python on e.g. macOS/RHEL.)

  • Make the unversioned python command optional (along with idle, pydoc, and python-config).
    Distributions now do not need to install it by default, even if Python 2 is installed. (But they should make it installable explicitly, as long as they ship Python 2.)
    This should introduce more people to systems without the "legacy" python command, encourage the use of explicit python2/python3, and ease switching to systems that don't have Python 2 at all.

  • Clarify that distributions should not make unversioned python configurable. (That might work for carefully managed systems, but the ecosystem should converge on python3, not "your python needs to be set properly".)

  • Remove mentions of choosing to link python to python3 in the future, as we don't expect to start recommending that.

  • Use the term "unversioned" python when contrasting it with python3/python2.
    I found that this makes the message much clearer.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@encukou
PEP 394: Allow not installing unversioned "python" command
fe6bd46 
The intended future for the ``python`` command is:

> ``python`` doesn't exist and one always has to specify ``python2``
> or ``python3``.

( – Guido, python#630 (comment) )

There are three conflicting ideas around the ``python`` command,
longer-term:

1. The ``python`` command should continue to refer to Python 2 (if
   Python 2 is available).
2. ``python`` is a correct shebang for py2/py3 source-compatible scripts.
3. Python 2 should *not* be available (by default / after 2010).

One of these has to give.
It seems that (2) is the easiest to shed, so this proposal does just that.

* Make ``python3`` the preferred shebang for py2/py3 compatible
  scripts, as that's the only shebang that'll work on py2-less systems.
  (An exception is made for scripts targetting the *system* Python
  on e.g. macOS/RHEL.)
* Make the unversioned ``python`` command optional (along with
  ``idle``, ``pydoc``, and ``python-config``).
  Distributions now do not need to install it by default, even if
  Python 2 is installed. (But they should make it installable
  explicitly, as long as they ship Python 2.)
  This should introduce more people to systems without the
  "legacy" ``python`` command, encourage the use of explicit
  ``python2``/``python3``, and ease switching to systems that don't
  have Python 2 at all.
* Clarify that distributions *should not* make unversioned
  ``python`` configurable. (That might work for carefully managed
  systems, but the ecosystem should converge on ``python3``, not
  "your ``python`` needs to be set properly".)
* Remove mentions of choosing to link ``python`` to ``python3`` in the
  future, as we don't expect to start recommending that.

* Use the term **"unversioned"** ``python`` when contrasting it with
  ``python3``/``python2``.
  I found that this makes the message much clearer.
@the-knights-who-say-ni the-knights-who-say-ni added the CLA signed label Feb 13, 2019
@encukou

encukou commented Feb 13, 2019

Copy link
Copy Markdown
Member Author

Note:

I'm responsible for how this is handled in RHEL 8 beta, where /usr/bin/python is configurable (though configuring it is discouraged).
I don't recommend that in the PEP – I don't think it needs to cover distros that need to lock in the behavior of /usr/bin/python for a decade.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou
Fix link to the pull request with these changes
0ef005e
@Rosuav

Rosuav commented Feb 13, 2019

Copy link
Copy Markdown
Contributor

It sounds to me like you're suggesting that py2/py3 compatible scripts be basically indistinguishable from Python 3 scripts, which in turn implies that a Python 3.x needs to be installed, even though the script could easily run on Py2. Is that your intention?
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou

encukou commented Feb 13, 2019

Copy link
Copy Markdown
Member Author

@Rosuav: Yes. In my opinion, that's the least bad option.
Note that Python 3 is available on the vast majority of systems. Notable exceptions I know of:

  • macOS-provided Python, which AFAIK doesn't even have python2, so it's basically a lost cause
  • RHEL 7 (we're working on that, but I'm not allowed to say much more)
  • Old OSes where people don't install new things lightly
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@Rosuav

Rosuav commented Feb 13, 2019

Copy link
Copy Markdown
Contributor

Cool. I'm absolutely okay with it too, but then, I'm one of those early adopters who runs everything on alpha releases, so my opinion carries little weight :)
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@vstinner

vstinner commented Feb 13, 2019

Copy link
Copy Markdown
Member

Related thread on python-dev: https://mail.python.org/pipermail/python-dev/2019-February/156272.html
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@FlyingWombat

FlyingWombat commented Feb 15, 2019 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown

So, I'm pretty new to Python, but:
Can I ask what the rationale is for removing python?
IMO using python3 makes Python 3.x seem like a fork of Python 2.x. But I thought the intent was the other way around: that Python 2.x would be the "fork", if it is to continue to exist. Isn't that whole idea of Python 2 End of Life?

I know a lot of distros kept python as python2, to preserve compatibility with legacy python programs. But IMO that's a backwards way of doing things.
Pretty much every other program I know of has foo execute the latest version, and then maybe older versions can be installed as fooX.Y. That makes more sense to me.
Nc432o5, artizirk, Ablesius, cclauss, and ncoghlan reacted with thumbs up emoji
All reactions
  • 👍 5 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@FlyingWombat FlyingWombat mentioned this pull request Mar 21, 2019
Python 3 as default python msys2/MINGW-packages#4950
Closed
@ncoghlan

ncoghlan commented Apr 25, 2019

Copy link
Copy Markdown
Contributor

@encukou Should this be closed in favour of #989?

@FlyingWombat The PEP is slowly being moved in that direction, but back when the PEP was first written (2011, just after Python 3.2 had been released), distros doing that was a genuinely bad idea, so we wanted to actively discourage them from doing it. The situation has changed a lot in the past eight years though, so the guidance needs to change accordingly.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou

encukou commented Apr 25, 2019

Copy link
Copy Markdown
Member Author

@encukou Should this be closed in favour of #989?

Ah, I knew I was forgetting something! Thanks for the reminder.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou encukou closed this Apr 25, 2019
@encukou
encukou deleted the pep-394-update branch April 25, 2019 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

CLA signed

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

6 participants

@encukou @Rosuav @vstinner @FlyingWombat @ncoghlan @the-knights-who-say-ni
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402520 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.