> Why do you think the stdlib *must *provide an example implementation
> for this specific scenario? Is there something unique to HTTP request
> handling that you feel is important to demonstrate?
*must* is too strong, but I would use a very strong *should*.
I think the stdlib should provide
On Mon, Feb 7, 2022 at 5:51 PM Jim J. Jewett wrote:
> There are problems with urllib. With hindsight, it would have been nice
> to do a few things differently. But that doesn't make migrating away from
> it any easier.
>
> This thread has mentioned several "better" alternatives -- but with the
On Wed, 9 Feb 2022 at 04:50, Christopher Barker wrote:
> So my thoughts:
>
> Rather than deprecate urllib, we refactor it a bit (and maybe deprecate parts
> of it), so that it:
>
> 1) contains the core building blocks: e.g. urllib.parse with which to build
> "better" libraries,
>
> 2) make the
On Tue, Feb 8, 2022 at 1:31 AM Marc-Andre Lemburg wrote:
> FWIW: I find this discussion a bit strange. Python's stdlib is
> supposed to provide basic tooling for a breadth of use cases,
> with emphasis on "basic" and "breadth".
>
> urllib is such a basic library and covers one of the main
> use
... and there are also plenty examples out there of using http.server as
a quick HTTP server for trying out new things, testing and teaching.
FWIW: I find this discussion a bit strange. Python's stdlib is
supposed to provide basic tooling for a breadth of use cases,
with emphasis on "basic" and
There are problems with urllib. With hindsight, it would have been nice to do
a few things differently. But that doesn't make migrating away from it any
easier.
This thread has mentioned several "better" alternatives -- but with the
exception of 3rd party Requests, the docs don't even
On Mon, Feb 7, 2022 at 4:56 AM Steve Dower wrote:
> On 2/6/2022 4:44 PM, Christian Heimes wrote:
> > 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
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
On 2/6/2022 4:44 PM, Christian Heimes wrote:
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
> 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.
Please don't remove urllib. There are mountains of code that rely on it. A
much better idea, IMO, would be to add a
On Sun, Feb 6, 2022 at 9:13 AM Paul Moore wrote:
> On Sun, 6 Feb 2022 at 16:51, Christian Heimes
> 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
On 2/6/22 6:08 AM, Victor Stinner wrote:
> I propose to deprecate the urllib module in Python 3.11. It would emit
> a DeprecationWarning which warn users, so users should consider better
> alternatives like urllib3 or httpx: well known modules, better
> maintained, more secure, support HTTP/2
Chiming in to say that whichever way this goes urllib3 would be okay. We can
always vendor the small amount of http.client logic we actually depend on for
HTTP connections. I do agree that the future of HTTP clearly lies outside the
standard library, our team is already thinking about ways to
On Sun, Feb 6, 2022 at 3:35 PM Paul Moore wrote:
> urllib.request may not be "best practice", but it's still extremely
> useful for simple situations, and urllib.parse is useful for basic
> handling of URLs.Yes, the more complex aspects of urllib are better
> handled by external packages, but
El dom, 6 feb 2022 a las 9:12, Paul Moore () escribió:
> On Sun, 6 Feb 2022 at 16:51, Christian Heimes
> 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
On Sun, 6 Feb 2022 at 16:51, Christian Heimes 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
On Sun, 6 Feb 2022 at 14:15, Victor Stinner wrote:
> I propose to deprecate the urllib module in Python 3.11. It would emit
> a DeprecationWarning which warn users, so users should consider better
> alternatives like urllib3 or httpx: well known modules, better
> maintained, more secure, support
On 06/02/2022 15.08, Victor Stinner wrote:
Hi,
I propose to deprecate the urllib module in Python 3.11. It would emit
a DeprecationWarning which warn users, so users should consider better
alternatives like urllib3 or httpx: well known modules, better
maintained, more secure, support HTTP/2
That was just one example, here are others in the pip code base that
urllib.request is used for more than the pathname functions, they are all
vendored or tests but would still be disruptive to remove:
https://github.com/pypa/pip/blob/main/tests/lib/local_repos.py
On Sun, Feb 06, 2022 at 03:08:40PM +0100, Victor Stinner wrote:
> I propose to deprecate the urllib module in Python 3.11. It would emit
> a DeprecationWarning which warn users, so users should consider better
> alternatives like urllib3 or httpx: well known modules, better
> maintained, more
On Sun, Feb 6, 2022 at 3:48 PM Damian Shaw wrote:
>
> Pip vendors requests for network calls:
> https://github.com/pypa/pip/tree/main/src/pip/_vendor/requests
>
> But still does depend on functions from urllib.parse and urllib.request in
> many places:
>
Pip vendors requests for network calls:
https://github.com/pypa/pip/tree/main/src/pip/_vendor/requests
But still does depend on functions from urllib.parse and urllib.request in
many places:
https://github.com/pypa/pip/blob/main/src/pip/_internal/utils/urls.py
Damian (he/him)
On Sun, Feb 6,
Speaking from anecdotal experience, "urllib.parse" is a very popular and
highly depended on module, I would be shocked if removing it wouldn't be
very disruptive.
In fact a quick search of the replacement modules you mention see that they
all rely it on it, here is an example from each:
*
Strong -1 from me.
urllib.request may not be "best practice", but it's still extremely
useful for simple situations, and urllib.parse is useful for basic
handling of URLs.Yes, the more complex aspects of urllib are better
handled by external packages, but that's not sufficient argument for
I am not an expert about pip,
but it will be not a problem about installing the pip module once CPython
removes urllib module from stdlib?
Warm regards,
Dong-hee
2022년 2월 6일 (일) 오후 11:13, Victor Stinner 님이 작성:
> Hi,
>
> I propose to deprecate the urllib module in Python 3.11. It would emit
> a
25 matches
Mail list logo
