Remember us? It's your friendly CPython release team and we have something
we think you may like: The new alpha release of Python 3.10 is here, now
with 100% more pattern matching. If I were you, I would download it and
start playing with it. Extra points if you report us any bugs you find
along the way! Are you confused about all this pattern matching business?
Fear not, this release also includes some fantastic documentation and some
shiny new "What's new" entries.
Check them here and tell us how we can improve it:
What's new: https://docs.python.org/3.10/whatsnew/3.10.html
Go get the new alpha here:
*Note: The alpha was officially released yesterday, but my email client
failed to deliver this email to the mailing lists so I am reposting it.*
**This is an early developer preview of Python 3.10**
# Major new features of the 3.10 series, compared to 3.9
Python 3.10 is still in development. This release, 3.10.0a6 is the sixth
of seven planned alpha releases.
Alpha releases are intended to make it easier to test the current state of
new features and bug fixes and to test the release process.
During the alpha phase, features may be added up until the start of the
beta phase (2021-05-03) and, if necessary, may be modified or deleted up
until the release candidate phase (2021-10-04). Please keep in mind that
this is a preview release and its use is **not** recommended for production
Many new features for Python 3.10 are still being planned and written.
Among the new major
new features and changes so far:
* [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Remove wstr from
* [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing
union types as X | Y
* [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter
* [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line
numbers for debugging and other tools.
* [bpo-38605](https://bugs.python.org/issue38605): `from __future__ import
annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) is now
* [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional
Length-Checking To zip.
* [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context
managers are now officially allowed.
* [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate
* [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type
* [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural
Pattern Matching: Specification
* [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural
Pattern Matching: Motivation and Rationale
* [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural
Pattern Matching: Tutorial
* <small>(Hey, **fellow core developer,** if a feature you find important
is missing from this list, [let Pablo know](mailto:firstname.lastname@example.org
The next pre-release of Python 3.10 will be 3.10.0a7 ( last alpha release),
currently scheduled for Monday, 2021-04-05.
# More resources
* [Online Documentation](https://docs.python.org/3.10/)
* [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 Release
* Report bugs at [https://bugs.python.org](https://bugs.python.org).
* [Help fund Python and its community](/psf/donations/).
# And now for something completely different
Schwarzschild wormholes, also known as Einstein–Rosen bridges (named after
Albert Einstein and Nathan Rosen), are connections between areas of space
that can be modelled as vacuum solutions to the Einstein field equations,
and that are now understood to be intrinsic parts of the maximally extended
version of the Schwarzschild metric describing an eternal black hole with
no charge and no rotation. Here, "maximally extended" refers to the idea
that the spacetime should not have any "edges": it should be possible to
continue this path arbitrarily far into the particle's future or past for
any possible trajectory of a free-falling particle (following a geodesic in
Although Schwarzschild wormholes are not traversable in both directions,
their existence inspired Kip Thorne to imagine traversable wormholes
created by holding the "throat" of a Schwarzschild wormhole open with
exotic matter (material that has negative mass/energy).
Regards from rainy London,
Pablo Galindo Salgado
I was reading a discussion thread <https://gist.github.com/tiran/2dec9e03c6f901814f6d1e8dad09528e> about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking:
Christian Heimes wrote:
> Core dev and PyPA has spent a lot of effort in promoting venv because we don't want users to break their operating system with sudo pip install.
I don't think sudo pip install should break the operating system. And I think if it does, that problem should be solved rather than merely advising users against using it. And why is it, anyway, that distributions whose package managers can't coexist with pip-installed packages don't ever seem to get the same amount of flak for "damaging python's brand" as Debian is getting from some of the people in the discussion thread? Why is it that this community is resigned to recommending a workaround when distributions decide the site-packages directory belongs to their package manager rather than pip, instead of bringing the same amount of fiery condemnation of that practice as we apparently have for *checks notes* splitting parts of the stdlib into optional packages? Why demand that pip be present if we're not going to demand that it works properly?
I think that installing packages into the actual python installation, both via distribution packaging tools and pip [and using both simultaneously - the Debian model of separated dist-packages and site-packages folders seems like a reasonable solution to this problem] can and should be a supported paradigm, and that virtual environments [or more extreme measures such as shipping an entire python installation as part of an application's deployment] should ideally be reserved for the rare corner cases where that doesn't work for some reason.
How is it that virtual environments have become so indispensable, that no-one considers installing libraries centrally to be a viable model anymore? Are library maintainers making breaking changes too frequently, reasoning that if someone needs the old version they can just venv it? Is there some other cause?