On Wed, 30 Mar 2022 at 12:28, Steve Dower <steve.do...@python.org> wrote:
>
> On 30Mar2022 1132, Baptiste Carvello wrote:
> > Le 28/03/2022 à 18:44, Steve Dower a écrit :
> >> I think to most people "batteries included" doesn't necessarily mean
> >> "standard library," with all that implies. It just means "it came with
> >> the first thing that I installed" (or alternatively, "at no additional
> >> charge").
> >
> > A point I have not seen made, is that some uses really need *standard*
> > batteries.
>
> I've certainly not forgotten it, it's just every time I try to make the
> point it doesn't seem to help. So until I find a clear way to argue
> that, yes, a standard "datetime" value makes sense, but no, a standard
> "HTTP headers dictionary" is unnecessary, I'm avoiding bringing it up
> again ;)
I also strongly agree with this position, and do my best to argue it.
But as you say, it is hard to draw the line.
Here's some examples, which while not exhaustive, might give a flavour
of my views:
"Obviously" things that should be in the stdlib (basic data types or
algorithms):
re, datetime, collections, enum, dataclasses, decimal, fractions
(maybe borderline), statistics, itertools, functools, pathlib
Obvious stuff that's OS related:
os, io, threading, multiprocessing, concurrent.futures,
subprocess, asyncio, urllib.request
Core services:
sys, venv, sysconfig, warnings, atexit, gc, zipimport, runpy,
importlib, marshal, pickle
Standard development tools:
argparse, pdb, cprofile, typing (arguable in some ways)
Handling of key file and data formats:
struct, csv, json, tomllib, zlib, gzip, bz2 (borderline), zipfile,
tarfile, base64
Arguable cases of file formats, but with important use cases
xml (you may not like it, but it's still used a lot)
configparser (similarly, ini-style files are used a lot, for
better or worse)
email (this is an outlier, but the packaging metadata file format
uses it, so there's a bootstrapping issue if it's not in the stdlib)
I've missed a lot out, and I'm sure people will argue most of these,
but that's sort of the point - it's *hard* to come up with a blanket
statement on how we should approach "the stdlib", because there's so
much diversity in there. That's why my starting position is that we
should retain the stdlib - sure, we can remove (and add!) stuff, but
we should do so on a case by case basis, not based on some blanket
"minimise it because we don't have the manpower or we don't want to
support it" basis.
If writing and sharing small, one-off scripts that depended on
non-stdlib packages were *significantly* easier, I might revise my
position on some of the arguable cases. PEP 582 (Python local packages
directory) might make a big difference here. But at the moment, adding
a 3rd party dependency effectively alters what you're doing from
"writing a script I can share" to "developing an application" - and
that's a *big* step for many people. Quoting Nathaniel Smith from
https://mail.python.org/archives/list/distutils-...@python.org/message/YFJITQB37MZOPOFJJF3OAQOY4TOAFXYM/
(albeit in a slightly different context):
"""
This last point is important: as projects grow in complexity, and are
used by a wider audience, they often end up with fairly complex tool
specifications that have to be shared among a team.
"""
My argument is that relying only on the stdlib allows people putting
off the need to take that step up in complexity, and we shouldn't
dismiss how significant that is.
Paul
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/LYKBB6YVZYQTJHPVRR5YMWE5D6YNSENY/
Code of Conduct: http://python.org/psf/codeofconduct/
