On Sun, Mar 27, 2022 at 11:04 AM Paul Moore <p.f.mo...@gmail.com> wrote:
> > 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 think that's where the mistake happens, though. Someone who needs > "best of breed" is motivated (and likely knowledgeable enough) to make > informed decisions about what's on PyPI. But someone who just wants to > get the job done probably doesn't - and that's the audience for the > stdlib. A stdlib module needs to be a good, reliable set of basic > functionality that non-experts can use successfully. There can be > better libraries on PyPI, but that doesn't mean the stdlib module is > unnecessary, nor does it mean that the stdlib has to match the PyPI > library feature for feature. > > So here, specifically, I'd rather see urlllib be the best urlllib it > can be, and not demand that it turn into requests. Requests is there > if people need/want it. Actually, I think this is very hard to talk about in generalities. If. you look at the two examples I used, json and urllib, we have two different "problems". I would like to see a requests-like interface in the stdlib not because it's "best of breed", and has, e.g. more features or better performance, or ...., I would like to see it because it has a cleaner, simpler interface (the easy things should be easy) -- so I'm not necessarily advocating that the entirely of requests be brought in to the stdlib, or that request be made obsolete, but that we borrow a bit of its API. Which would also make the transition from stdlib to requests easier -- write you scripts with the stdlib, and when you find you need some more "advanced" features, you simpy drop requests in and move along. json is actually the opposite- most of the third-party json libs mimic (and maybe extend) the json API -- so you can, in most cases, start out with the stdlib, and drop in another app when you need more performance, or an extra feature. The issue I have with the stdlib json lib is that I think it could have a somewhat better API, and there's a few features I'd like to see it grow, so that third party libs are less necessary. But it seems there's not much motivation to do so, because "folks can always use a third party lib". Why is this an problem? two reasons: 1) There are quite a few json libs out there, and they tend to be a fourth party dependency (I just coined that term for a dependency of a dependency) . I literally have some of my code requiring four different json libs to run. It works, so maybe not a huge deal, but it would be really nice to simplify that! 2) I don't think any of the third party libs provide a full menu -- JSON5 support, performance, etc, so sometimes there's no single best of breed for even a particular application. Can/should that be solved by the stdlib? maybe not, but it would be nice to see it addressed somewhere -- a grand unification of JSON libs. In short: I think I agree with most folks here that we should still include the batteries, and they should be updated / maintained to some extent. What exactly could/should be done is going to have to be worked on on a case by case basis. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/WTBHIJKVU32OUJ7BGSBZP4HNTZAKT2TG/ Code of Conduct: http://python.org/psf/codeofconduct/
