On Mon, May 20, 2019 at 5:41 AM John Ladasky <john_lada...@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 -- https://mail.python.org/mailman/listinfo/python-list
