[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Change by Ned Deily : -- assignee: docs@python -> components: -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, C API, Cross-Build, Demos and Tools, Documentation, Extension Modules, FreeBSD, Interpreter Core, Parser, Regular Expressions, SSL, Tests, Unicode, Windows,

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Change by Ned Deily : -- hgrepos: -414 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Change by Ned Deily : Removed file: https://bugs.python.org/file50716/mitre_f188eec1268fd49bdc7375fc5b77ded657c150875fede1a4d797f818d2514e88_120.csv ___ Python tracker ___

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Change by qweqwe4844m : -- assignee: -> docs@python components: +2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, C API, Cross-Build, Demos and Tools, Documentation, Extension Modules, FreeBSD, Interpreter Core, Parser, Regular Expressions, SSL, Tests, Unicode, Windows,

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Senthil Kumaran added the comment: Hi all, I was looking at it. Introducing an enum at the last parameter is going to add cost of understanding the behavior to this function. I am doing further reading on the previous discussions and PR(s) now. --

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Senthil Kumaran added the comment: I will review this in a day. I had been following the conversation, but couldn't look deeper into the code. Thank you for engaging and contributions. -- ___ Python tracker

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Ethan Furman added the comment: Sounds good. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Éric Araujo added the comment: I would like to know what Senthil is thinking before the PR with options à la carte are merged! -- ___ Python tracker ___

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Ethan Furman added the comment: Éric Araujo wrote on PR30520: > No, we should not redefine the behavior of urlparse. > > I was always talking about adding another function. Yes it can be a one-liner, > but my point is that I don’t see the usefulness of having the

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Change by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

karl added the comment: Just to note that there is a maintained list of officially accepted schemes at IANA. https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml In addition there is a list of unofficial schemes on wikipedia

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Lincoln Auster added the comment: > In my idea it would not be a list of things that you have to pass > piecemeal to request specific behaviour, but another function or a new > param (like `parse(string, universal=True)`) that implements universal > parsing. If I'm correct in my understanding

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Éric Araujo added the comment: In my idea it would not be a list of things that you have to pass piecemeal to request specific behaviour, but another function or a new param (like `parse(string, universal=True)`) that implements universal parsing. We could even handle things like #22852 in

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Lincoln Auster added the comment: > Maybe a new parse function, or new parameter to the existing one, > could be easier to add. If I'm understanding you right, that's what this (and the PR) is - an extra optional parameter to urllib.parse to supplement the existing (legacy?) hard-coded list.

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Éric Araujo added the comment: I remember a discussion about this years ago. urllib is a module that pre-dates the idea of universal parsing for URIs, where the delimiters (like ://) are enough to determine the parts of a URI and give them meaning (host, port, user, path, etc). Backward

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

Change by Lincoln Auster : -- keywords: +patch pull_requests: +28721 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30520 ___ Python tracker ___

[issue46337] urllib.parse: Allow more flexibility in schemes and URL resolution behavior

New submission from Lincoln Auster : It looks like this was discussed in 2013-2015 here: https://bugs.python.org/issue18828 Basically, with all the URL schemes that exist in the world (and the possibility of a custom scheme), the current strategy of enumerating what do what in a hard-coded