Am 27.03.22 um 18:11 schrieb Christopher Barker:
On Sun, Mar 27, 2022 at 3:08 AM Paul Moore <p.f.mo...@gmail.com> wrote:
> > 3. Overall, I think the days where "battery included" was a
positive argument are over
>
> I strongly disagree. Being able to download something and
immediately get something to work and see results is hugely
> rewarding; on the other hand, having to research, find, compare
& contrast available third-party modules (especially for
> new-comers) can be extremely discouraging.
exactly - let's say someone needs to write some JSON for the first time.
I think the truth is somewhere in the middle. Python should include
support for commonly needed functionality. This includes all kinds of
language support (functools, collections, asyncio, wsgiref, re etc.),
common file formats like XML, JSON, tar, zip etc., OS support (os, sys,
stat etc.), basic networking (TCP/IP, making HTTP requests, sending
mail), but also basic math modules like decimal, fractions, or
statistics. I don't think it should support esoteric, niche, or long
obsolete file formats or networking protocols like FTP, sunau etc. I
also don't think that Python should come with "basic" servers that can't
be used for anything useful. The same is true for domain-specific
applications. For example, I wouldn't want a complex numerics package as
part of Python (although having some more basic data types would make
sense).
Another problem are "optional" modules like sqlite or tk/tcl. Because
they are optional, you can't depend on them being present, but you also
can't ensure their presence by "pip install"ing them.
In fact, this is an example, I think, of where we should put some
effort into making the included batteries better -- it's great to have
a JSON lib built in, but it's too bad that it's not best-of-bread by
pretty much any definition (speed, memory performance, flexibility) --
there are quite a few feature requests open for it -- it would be nice
to actually implement some of those. (but yes, that's a lot of work
that someone(s) would have to do)
Back to the topic at hand, rather than remove urllib, maybe it could
be made better -- an as-easy-to-use-as-requests package in the stdlib
would be really great.
I agree 100%. On the one hand the stdlib is missing some functionality I
would consider "basic" (for example, async file and HTTP fetching
support), on the other hand some of the existing modules would benefit
from a more modern API that makes the common case easy and the uncommon
case possible.
- Sebastian
_______________________________________________
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/RZFGUDPO2DIASHI72GUF2NP3IR3DLQGO/
Code of Conduct: http://python.org/psf/codeofconduct/
