One of Python's original selling points was that it was "batteries included".
That is to say, its standard library was quite large. While it still has
an extensive standard library, the standard library seems to have ossified somewhat.
Since 2016, nearly all additions to the standard library have been either to the
asyncio modules. While there have been a couple of new non-typing or async
modules since, those are unlikely to be found by new users (e.g
A slew of standard library modules have even been deprecated in python 3.9 or 3.10.
Meanwhile, modern languages often come with even larger standard libraries and/or
If Python does not want to get outclassed by the new kids on the block, it could use some recharging of its batteries.
Here are a few suggestions I would like to see in the standard library, and/or bundled together with a regular python install. These are items that currently rely on extremely widespread third-party packages.
I find it a little surprising there is no TOML parser in the standard library. After
all, TOML files are effectively required
for storing project metadata and build specs.
This means any modern python build system has a hard dependency on
tomli, which is a
bit of a circular dependency which has already left Linux distro maintainers up in arms
for good reason.
Let's be honest. What project does not depend on
requests, be it directly or
transitively? Making URL requests is just basic functionality for many tasks in 2022.
urllib exists, but it isn't as user-friendly, and its own documentation
already recommends the use of
The usual arguments that the standard library is a place where packages go to die does not hold much water here as well. In all of 2021, there was just one release, and the just-released 2.27 release's main feature was python 3.10 support. It is already being developed under the auspices of the Python Software Foundation, so moving (part of) it to the standard library probably makes that less difficult than it would be for other packages.
While python has extensive support for handling dates and datetimes under the
datetime module, use of this module is often a source of subtle bugs. There is good
reason why third-party packages such as pendulum are
The use of naive datetimes by default may have made sense in the 1990s, but in today's
globalized world one cannot dispense with timezones. Not to mention the surprising
behaviour of things like
datetime.datetime.utcnow() returning a naive datetime
with a plainly wrong UNIX timestamp.
Python is of course not alone in this. Other languages have made the exact same
mistakes in the past. Changing the behaviour of such a fundamental module would
obviously lead to a world of pain for existing systems. A new,
timezone-aware-by-default datetime module living alongside or building on top of
datetime therefore seems like a good idea. Inspiration could be taken from Java's
Rust's chrono crate and Golang's time package.
Surprisingly few development tools come out of the box with a standard python install. This is in stark contrast to newer languages such as Rust or Golang which come with a swiss army knife full of tools. Instead, python relies on third-party packages. I'd argue at least some of those could be part of the standard python install. Newcomers to Python cannot be assumed to be familiar with virtualenv, system vs user installs, pip, ensure-pip, site-packages, etc. Reducing the amount of third-party packages that must be correctly installed for effectively any and all projects would therefore make python less intimidating to newcomers.
Whether such tools would be subcommands to
python, modules enabled with
separate executables is something I'd be ambivalent to.
Both Rust and Golang come with a code formatter out of the box, via
cargo fmt and
go fmt, respectively.
The python ecosystem of course has
black, which takes in the same role. This is
something I install for literally every project. Having an automatic code formatter
does away with bike-shedding arguments over which style is correct, which is
unfortunately all too common in projects that do not use a code formatter. In addition,
making sure there is just one obvious way of doing something also fits the Zen of Python.
You might say, we already have
doctest, do we really need yet another
framework in the standard toolset? Yeah, maybe. This is again something both Rust
and Go do a lot better than Python. In Rust one simply writes a
in Go one simply writes a function starting with
Test, and both languages'
cargo test and
go test) automatically pick up test cases. Both these
languages therefore make tests first class citizens.
Why can't I just type something like
python -m test and have something similar for
python, without having to first download and install a third-party package?
Like with the
requests module, the
already mentions that third-party package,
In recent years, a lot of focus has been on the optional type hinting features. This has largely been very successful, with type hints being widespread in the community.
That said, making practical use of the type hints involves installing some type checker.
Again, these are third-party packages that do not come bundled with Python.
The current situation in the Python landscape is akin to Typescript not coming with
mypy type checker is already being developed under the Python organization,
I feel it would make a lot of sense to distribute it along with a standard Python