[DO NOT MERGE] PEP 548: Initial draft of PEP 394 update - #315
Conversation
|
There are a few folks I'd like to take a look at this before I publish even the first draft, so I'm happy to take the risk of colliding on the PEP number in the meantime :) |
| refers to ``python3`` should be updated to run in the common subset of Python | ||
| 2.7 & 3.6+ using either the `regular porting guide`_ in the Python reference | ||
| documentation or else the `conservative porting guide`_ developed as part of | ||
| Fedora's migration to using Python 3 as the system Python runtime. |
There was a problem hiding this comment.
This PEP allows /usr/bin/python to be missing altogether. That leaves these scripts in a tough situation – there is no shebang that will work everywhere.
I think the PEP should say that the python command might be missing, but should always be installable, so that running such portable scripts would be possible on all systems.
There was a problem hiding this comment.
After writing https://fedoraproject.org/wiki/User:Ncoghlan/Default_python_module I'm actually wondering if I should put something in the migration notes about providing a custom error message that explains how to set /usr/bin/python to something sensible when it's absent by default, because the standard error message from Fedora's shebang handler is pretty unhelpful, and I assume we're far from alone in that :)
There was a problem hiding this comment.
Maybe we need a pylingual executable? :)
I do like the idea of recommending a shebang that can be counted on to exist, but may be either Python 2 or Python 3, and specifically also recommending to use that for scripts that are bilingual. I'd love to repurpose /usr/bin/python for that, but I think it will make migration to an all-Python 3 world later on more difficult.
Then again, we get conflated with the name of the thing that users run on their console to invoke a Python interpreter.
Aside from that, I don't think we need to talk about the porting guides here. There are plenty of ways to find those resources, and that information isn't immediately relevant to folks trying to implement this PEP. Let's keep it short, sweet, and prescriptive!
|
I think the PEP should be limited to actionable points and relevant rationale. |
warsaw
left a comment
There was a problem hiding this comment.
I stopped reviewing once I got to the rationale. That's useful information perhaps but makes the PEP more unwieldy. If we adopt this as a replacement for 394 (which I still think is unnecessary), then we should pare this down and find some other home for that information.
| command), and without requiring platforms to provide parallel Python 2 & 3 | ||
| stacks indefinitely. | ||
|
|
||
| * ``python2`` will refer to some version of Python 2.x. |
There was a problem hiding this comment.
Since it's the goal eventually to remove Python 2 entirely, maybe say:
- If Python 2 is available,
python2MUST refer to some version of Python 2.7 python3MUST refer to some version of Python 3.x, where x >= 5pythonMAY be absent, refer to Python 2.7, or revert to Python 3.x, where x >= 5
(Why is 3.6+ the minimum requirement?)
| * ``python`` should either be absent, refer to Python 2.7 *or* refer to | ||
| Python 3.6+. | ||
| * if a ``python`` link is provided, the target Python interpreter should provide | ||
| the ``six`` compatibility library by default. |
There was a problem hiding this comment.
It is possible to write bilingual code without six, so why is it required?
| continue to be portable across ``*nix`` systems, regardless of the default | ||
| version of the Python interpreter (i.e. the version invoked by the ``python`` | ||
| command), and without requiring platforms to provide parallel Python 2 & 3 | ||
| stacks indefinitely. |
There was a problem hiding this comment.
Should we specifically say /usr/bin/{python,python2,python3}? We're not making recommendations about anything outside /usr/bin, e.g. you can do with /usr/local/bin whatever you want.
| stacks. | ||
|
|
||
|
|
||
| Recommendations for Development of Standalone Scripts |
There was a problem hiding this comment.
Maybe, "Shebang line recommendations for deployed scripts"?
I read "Development" here to refer to how you develop your scripts locally, and there are of course plenty of options there. We want to make recommendations for how platform vendors will provide Python scripts to their users.
| gain compatibility with platforms that only provide Python 3.x, should | ||
| specifically target ``python2`` (as this is available by default almost | ||
| everywhere that Python 2 is available, and is easily added as a symlink if | ||
| it is missing). |
There was a problem hiding this comment.
I think this can be written more succinctly has:
- standalone scripts which are only, and will only be, compatible with Python 2 should target
python2.
| ``python2`` (for full compatibility with Python-2-only distributions) or | ||
| ``python3`` (for compatibility with cross-version shebang lines without | ||
| installing a second Python runtime environment) (e.g. proposal currently | ||
| in development for Fedora 27+) |
There was a problem hiding this comment.
So basically, you can't really count on python being anything or even present! :)
| * The Python 2.x ``idle``, ``pydoc``, and ``python-config`` commands should | ||
| be made available as ``idle2``, ``pydoc2``, and ``python2-config``, | ||
| with the original unqualified commands invoking either ``python2`` or | ||
| ``python3`` in accordance with the target version for ``python``. |
There was a problem hiding this comment.
What about the Python 3 versions of these? Should this be a stronger recommendation and say that the unadorned names MUST track the python link? And what about third party tools that are version-sensitive?
| * Regardless of whether it refers to ``python2`` or ``python3``, if a ``python`` | ||
| link is provided the target Python stack should include the``six`` | ||
| compatibility library by default, as having this library available | ||
| significantly increases the common subset of Python 2.7 and 3.6+. |
There was a problem hiding this comment.
I'm still not completely convinced about this one.
| (restored in 3.5) | ||
| * improved error messages for Python 2 style print statements (initially | ||
| improved in 3.4.2, subsequently enhanced further with suggested calls to | ||
| the print builtin in 3.6.3) |
There was a problem hiding this comment.
Is this important enough to floor on Python 3.6? Maybe, especially since it is the current stable release. 3.5 might be EOL'd by the time this PEP takes effect (I haven't done the math ;).
| * If a ``python`` link targets ``python3``, the platform should also implement | ||
| PEP 538's locale coercion or a comparable mechanism in order to reduce the | ||
| likelihood of unexpected Unicode decoding and encoding errors when running | ||
| standalone scripts that expect Python 2's permissive Unicode handling model |
|
@warsaw @encukou Given that https://portingguide.readthedocs.io/ exists, what do you think of the idea of adding a new section to the end of that about "Enabling Python 3 Migrations"? Rather than being written for Python developers, it would be written for Python distributors, and would become the home for the non-prescriptive parts of PEP 394 where we're more writing about "Issues to consider" rather than offering specific recommendations (because the right answer is going to depend heavily on the particular redistributor's target audience). That would let us drop the Rationale and Migration Notes sections from the PEP, and instead say "For more in-depth discussion of the design trade-offs to consider when enabling end user migrations from Python 2 to Python 3, see [link]". |
|
It could live there, but I don't think I'd want it under the conservative porting guide. It can live in its own space, though -- should I set one up? |
|
@encukou Now that you suggest it, I think having a collaborative "Python Redistributor's Guide" would be a very good idea. Even without considering the challenges of the Python 3 migration, there are lots of things that are easy to get wrong that aren't specific to any one distribution channel (e.g. the fact that 2.7 should use narrow builds on Windows and wide builds every else for binary compatibility with PyPI wheels, or missing the opportunity to offer PGO builds instead of regular ones). |
|
Since we're going to go in a very different direction with this (updating PEP 394 in place + creating a separate Redistributor's Guide), I'm going to close this PR and free up PEP 548 for other uses. |
|
I've created a repository for the redistributor's guide, and filed an issue there to explain why I created it and what I plan to do with it: python/redistributor-guide#1 |
No description provided.