Amber Brown: Batteries Included, But They're Leaking

[Chris Angelico]

On Mon, May 20, 2019 at 5:41 AM John Ladasky <john_ladasky at sbcglobal.net> wrote:
>
> On Saturday, May 18, 2019 at 2:21:59 PM UTC-7, Paul Rubin wrote:
> > http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html
> >
> > This was a controversial talk at the Python language summit, giving
> > various criticisms of Python's standard library,
>
> I will try to find some time to read through Amber Brown's remarks.

I'll make a few comments too.

> Applications Need More Than The Standard Library
>
> For example, asyncio requires external libraries to connect to a database or to speak HTTP.

Nothing in Python's standard library connects to a database (with the
minor exception of sqlite3, which isn't so much "connecting to a
database" as "reading a database file"). This is not a dependency of
asyncio any more than psycopg2 (from PyPI) is a dependency of the
socket module.

HTTP might be a valid point, as many applications could restrict
themselves to the stdlib if working synchronously or with threads, but
to do so with asyncio would require manually crafting HTTP requests
and parsing HTTP responses. Would have to confirm that, though; is it
possible to use asyncio's socket services with other modules in the
stdlib?

> Brown asserted that there were many such dependencies from the standard
> library to PyPI:

No, that is not a dependency. A dependency is where something cannot
run without something else. Nothing in the stdlib depends on anything
from PyPI. Claiming that an application needs a library from PyPI is
not the same as showing a dependency.

> typing works best with mypy,

The point of the typing module is to be the baseline that makes
annotations legal and executable, without giving them actual meaning.
Good use of mypy (or any other type checker - it's intentionally
generic) can be by publishing something that depends only on the
stdlib, but on your development computer, you install mypy. This is
the entire point of the typing module - to be part of the stdlib and
allow the code to run unmodified (but unchecked).

> the sslmodule requires a monkeypatch to connect to non-ASCII domain names,

Is that true? If confirmed, that should just be raised as an issue and
dealt with.

> datetime needs pytz,

You can easily use datetime without timezone support, either just
using naive datetimes, or using UTC. The stdlib includes support for
fixed UTC offsets too, but not daylight saving time. Considering that
the tzdata files get updated about ten times a year, baking that into
the stdlib would be a bad idea.

> and six is non-optional for writing code for Python 2 and 3.

Absolutely false. I have written 2/3 spanning code without six. It's a
convenience, and most assuredly not "non-optional". Also, writing
Py3-only code is a completely reasonable choice, especially as 2020
approaches.

> Other standard library modules are simply inferior to alternatives on PyPI.

Honestly, not surprised. If the stdlib modules were superior to the
PyPI ones, the latter wouldn't exist. There are plenty of reasons for
superior options to be installable, and that's not a problem. The
stdlib is there for people who want to be strict about deployment,
which makes it easier for people to use a script.

> The http.client documentation advises readers to use Requests,

And that's a prime example; the requests module changes too frequently
to be baked into the stdlib usefully.

> and the datetime module is confusing compared to its competitors such as arrow, dateutil, and moment.

I've never even heard of arrow. Not sure what the issue is with
datetime; more details needed.

> Standard Library Modules Crowd Out Innovation
>
> Brown’s most controversial opinion, in her own estimation, is that adding modules to
> the standard library stifles innovation, by discouraging programmers from using
> or contributing to competing PyPI packages.

This opinion is in direct conflict with the prior complaint that there
are stdlib modules inferior to third-party ones.

> Van Rossum argued instead that if the Twisted team wants the ecosystem to
> evolve, they should stop supporting older Python versions and force users to
> upgrade. Brown acknowledged this point, but said half of Twisted users are
> still on Python 2 and it is difficult to abandon them. The debate at this point
> became personal for Van Rossum, and he left angrily.

And this is what happens when you look at statistics to make your
decisions. So long as you say "half of Twisted users are on Python 2,
we have to support it", those users will say "Twisted still supports
Python 2, we don't have to move". Maybe it's not about abandoning
people but about drawing them onto a more recent Python.

> Brown said her point was to move asyncio to PyPI, along with most new
> feature development. “We should embrace PyPI,” she exhorted.

This is the only "action item" I've found in the entire rant. Quite
aside from the backward incompatibility in the specific example of
removing asyncio from the stdlib, there IS still a lot of value in
keeping things in the core distribution. For large projects, it's easy
and common to include a "requirements.txt" and depend on PyPI; but for
small projects, it's much easier to distribute just a single .py file
and expect it to be able to run on every Python system.

Python *does* embrace PyPI. Thanks to ensurepip, most Python
distributions are capable of installing third-party packages. There
are some ongoing issues such as difficulties installing on Windows,
but they don't seem to be the point of this rant.

So what IS the point of this rant? What should be being fixed? It
would be a bad thing for Python to remove things from the stdlib. It
would also be a bad thing to adopt a policy of "no further stdlib
packages, everyone needs to use PyPI". If that's the only suggested
action, this is nothing more than a rant. Need more proposed
solutions.

ChrisA