urllib: addressing inflexibility in scheme-based joining
Hi, About a month ago, I opened BPO 46337 with regard to urllib's inflexible handling of URL schemes. (Another discussion (from 2013) occured in BPO-18828.) In my ticket, I proposed supplementing the hard-coded uses_* scheme lists that control URL parsing and joining behavior with an enum that may override behavior when calling a function that would effect it. (More detail is available in BPO 46337 and potential code is available in cpython PR#30520.) Do you think this would be a generally useful/good thing to have? Comments, questions, feedback? This would be my first interaction with Python development, so I'm not too certain about where everything goes. Rereading the dev docs, it looks like the appropriate channel for discussion of this is on this mailing list, not BPO. Github just reminded me that my PR is stale, so I figured I'd retry this whole thing with a closer look at the dev documentation - thanks for bearing with me :) -- Lincoln Auster They/Them
This is background on Python development and a current issue, I don't have a strong opinion on whether effort should be devoted to improving urllib. Lincoln Auster writes:
Compliments on an excellent executive summary!
Do you think this would be a generally useful/good thing to have?
LGTM, but you should be aware that recently it was proposed (by Victor Stinner, IIRC) that urllib be deprecated. The (long) thread is on Python-Dev. Summmary: While the pushback against deprecation was pretty fierce, there's also a fair amount of sentiment that for serious use[1] urllib is either obsoleted by 3rd party packages or needs a fair amount of "fencing" for robustness and security. It remains a package of choice for basic use, and evidently components of it are used in those 3rd party packages. I don't have an opinion about what this means for your proposal, but you should be aware of it. I suggest that you carefully distinguish your proposal from that thread.
This would be my first interaction with Python development,
If you want a guided tour of the process, and possibly a committer who would act as proponent, the core-mentorship@python.org list is the place to meet a mentor. (I don't think you need one, but everybody's allowed to ask for help.)
I don't think this rises to the level where you need public discussion as long as no existing features change, so starting with BPO and a PR was the right choice. If your PR has gone stale, you do want to make a request for comments either here or Python-Dev. Python-Dev is a better choice for a pure RFC (more committers there and they're much quicker to respond there), but I think it's easier to stay away from the deprecation[2] controversy here, so: good choice! Footnotes: [1] Ie, B2X or other activity likely to attract Internet ruffians. [2] It's not really a *deprecation* controversy any more, but not sure what else to call it. ;-)
This is background on Python development and a current issue, I don't have a strong opinion on whether effort should be devoted to improving urllib. Lincoln Auster writes:
Compliments on an excellent executive summary!
Do you think this would be a generally useful/good thing to have?
LGTM, but you should be aware that recently it was proposed (by Victor Stinner, IIRC) that urllib be deprecated. The (long) thread is on Python-Dev. Summmary: While the pushback against deprecation was pretty fierce, there's also a fair amount of sentiment that for serious use[1] urllib is either obsoleted by 3rd party packages or needs a fair amount of "fencing" for robustness and security. It remains a package of choice for basic use, and evidently components of it are used in those 3rd party packages. I don't have an opinion about what this means for your proposal, but you should be aware of it. I suggest that you carefully distinguish your proposal from that thread.
This would be my first interaction with Python development,
If you want a guided tour of the process, and possibly a committer who would act as proponent, the core-mentorship@python.org list is the place to meet a mentor. (I don't think you need one, but everybody's allowed to ask for help.)
I don't think this rises to the level where you need public discussion as long as no existing features change, so starting with BPO and a PR was the right choice. If your PR has gone stale, you do want to make a request for comments either here or Python-Dev. Python-Dev is a better choice for a pure RFC (more committers there and they're much quicker to respond there), but I think it's easier to stay away from the deprecation[2] controversy here, so: good choice! Footnotes: [1] Ie, B2X or other activity likely to attract Internet ruffians. [2] It's not really a *deprecation* controversy any more, but not sure what else to call it. ;-)
participants (2)
-
Lincoln Auster -
Stephen J. Turnbull