While the PEP does show the version number as part of the path to the
actual packages, implying support for multiple versions, this doesn't seem
to be spelled out in the actual text. Presumably __pypackages__/3.8/ might
sit beside __pypackages__/3.9/, etc. to keep future versions capable of
installing packages for each version, the way virtualenv today is bound to
one version of Python.
I'd like to raise a potential edge case that might be a problem, and likely
an increasingly common one: …
[View More]users with multiple installations of the *same*
version of Python. This is actually a common setup for Windows users who
use WSL, Microsoft's Linux-on-Windows solution, as you could have both the
Windows and Linux builds of a given Python version installed on the same
machine. The currently implied support for multiple versions would not be
able to separate these and could create problems if users pip install a
Windows binary package through Powershell and then try to run a script in
Bash from the same directory, causing the Linux version of Python to try to
use Windows python packages.
I'm not actually sure what the solution here is. Mostly I wanted to raise
the concern, because I'm very keen on WSL being a great entry path for new
developers and I want to make that a better experience, not a more
confusing one. Maybe that version number could include some other unique
identify, maybe based on Python's own executable. A hash maybe? I don't
know if anything like that already exists to uniquely identify a Python
build or installation.
--
CALVIN SPEALMAN
SENIOR QUALITY ENGINEER
cspealma(a)redhat.com M: +1.336.210.5107
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
[View Less]
While the switch to Python 3 did an excellent job in removing some of
the old inconsistencies we had in the language, pretty much everyone
agrees that some other backwards-incompatible changes could be made to
remove some old warts and bring even more consistency to Python.
Since Python 4 is getting closer and closer, I think it’s time to
finally discuss some of the most obvious changes we should do for
Python 4. Here is the list I compiled:
- The / operator returns floats, which loses …
[View More]information when both of
the operands are integer. In Python 4, “1 / 2” should return a
decimal.Decimal. To ease the transition, we propose to add a new “from
__future__ import decimal_division” in Python 3.9 to enable this
behavior.
- As most of the Python ecosystem is moving towards async, some of the
old I/O-blocking APIs should be progressively migrated to an async by
default model. The most obvious candidate to start this transition is
the print function, which blocks on the I/O of flushes. We propose to
make “print” an async coroutine. In Python 3.9, this feature could be
optionally enabled with “from __future__ import print_coroutine”.
- To ease compatibility with the Windows API, the PyUnicode* objects
should be internally represented as an array of uint16_t, as it would
avoid the conversion overhead from UCS. CPython migration details are
left as an exercise for the developer.
We think more changes are obviously warranted (e.g adding a new string
formatting module, changing the semantic of the import system, using
:= in with statements...), but these changes will need specific
threads of their own.
So, can you think of other backward-incompatible changes that should
be done in Python 4? Don't hesitate to add your own ideas :-)
Thanks,
--
Antoine Pietri
[View Less]