My two cents:
1. I’ve grepped ("ag-ed" acually) through all my code bases, and as noted
by others, urllib.parse is used in many places. urllib.request never is, as
we've been using requests or httpx instead.
IMHO and for the context I'm using it (YMMV), urllib.parse is useful and
should be kept (could be replaced by third-party libs like furl or yarl,
but probably not a great idea).
2. Obviously bootstrapping pip or similar package management tools should
be a concern.
3. Overall, I think the days were "battery included" was a positive
argument are over. I'd rather make the standard library leaner, and
focussed on core language constructs. The only advantage that I can see is
that having stuff in the standard lib can reduce fragmentation, at least
initially, and ensure a very high level of quality and support, but at some
point in the future history has shown us that usually a better alternative
ends up emerging.
4. When deprecating and removing stuff from the stdlib and if there are no
dependency issues, it should be possible to more the components to their
own dedicated packages, maybe under an "extra" or "legacy" organisation.
The question of support stays open, though.
Regards,
S.
On 6 Feb 2022 at 23:39:55, Gregory P. Smith <g...@krypto.org> wrote:
>
>
> On Sun, Feb 6, 2022 at 9:13 AM Paul Moore <p.f.mo...@gmail.com> wrote:
>
>> On Sun, 6 Feb 2022 at 16:51, Christian Heimes <christ...@python.org>
>> wrote:
>>
>> > The urllib package -- and to some degree also the http package -- are
>> > constant source of security bugs. The code is old and the parsers for
>> > HTTP and URLs don't handle edge cases well. Python core lacks a true
>> > maintainer of the code. To be honest, we have to admit defeat and be up
>> > front that urllib is not up to the task for this decade. It was designed
>> > written during a more friendly, less scary time on the internet.
>> >
>> > If I had the power and time, then I would replace urllib with a simpler,
>> > reduced HTTP client that uses platform's HTTP library under the hood
>> > (WinHTTP on Windows, NSURLSession (?) on macOS, Web API for Emscripten,
>> > maybe curl on Linux/BSD). For non-trivial HTTP requests, httpx or
>> > aiohttp are much better suited than urllib.
>> >
>> > The second best option is to reduce the feature set of urllib to core
>> > HTTP (no ftp, proxy, HTTP auth) and a partial rewrite with stricter,
>> > more standard conform parsers for urls, query strings, and RFC 2822
>> > instead of RFC 822 for headers.
>>
>> I'd likely be fine with either of these two options. I'm not worried
>> about supporting "advanced" uses. But having no way of getting a file
>> from the internet without relying on 3rd party packages seems like a
>> huge gap in functionality for a modern language. And having to use a
>> 3rd party library to parse URLs will simply push more people to use
>> home-grown regexes rather than something safe and correct. Remember
>> that a lot of Python users are not professional software developers,
>> but scientists, data analysts, and occasional users, for whom the
>> existence of something in the stdlib is the *only* reason they have
>> any idea that URLs need specialised parsing in the first place.
>>
>> And while we all like to say 3rd party modules are great, the reality
>> is that they provide a genuine problem for many of these
>> non-specialist users - and I say that as a packaging specialist and
>> pip maintainer. The packaging ecosystem is *not* newcomer-friendly in
>> the way that core Python is, much as we're trying to improve that
>> situation.
>>
>> I've said it previously, but I'll reiterate - IMO this *must* have a
>> PEP, and that PEP must be clear that the intention is to *remove*
>> urllib, not simply to "deprecate and then think about it". That could
>> be making it part of PEP 594, or a separate PEP, but one way or
>> another it needs a PEP.
>>
>
> This would need to be it's own PEP. urllib et. al. are used by virtually
> everybody. They're highly used batteries.
>
> I'm -1 on deprecating it for that reason alone.
>
> Christian proposes that having a simpler scope rewrite of it might be
> nice, but I think disruption to the world and loss of trust in Python would
> be similar either way.
>
> -gps
>
>
>>
>> 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/KT6TGUBTLLETHES2OVVGZWSGYC5JCEKC/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> 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/QMSFZBQJFWKFFE3LFQLQE2AT6WKMLPGL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Co-Founder & Co-Chairman, National Council for Free & Open Source Software
(CNLL) - http://cnll.fr/
Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel
Libre (APELL) - https://www.apell.info/
Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) -
https://www.euclidia.eu/
Founder, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
_______________________________________________
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/CNLKWRZTH5LGL2X62UORZMOI5PK7ROXR/
Code of Conduct: http://python.org/psf/codeofconduct/
