bpo-46337: Urllib.parse scheme-specific behavior without reliance on URL scheme #30520

oldaccountdeadname · 2022-01-10T21:55:14Z

See bpo-46337. Basically, this allows code like this:

>>> urljoin("custom-scheme://a.host/loc", "..", "custom-scheme://a.host/", classes=[urllib.parse.SchemeClass.RELATIVE, urllib.parse.SchemeClass.NETLOC])
'custom-scheme://a.host/'

https://bugs.python.org/issue46337

Some features in urllib are dependent on schemes, (i.e., preserving the netloc in url joining). Prior to this patch, this was governed by the uses_* lists (uses_relative, uses_netloc, uses_params) which hard code these attributes for certain schemes. Providing an enum interface and a 'constructor' that allows overrides makes this mechanism a bit more flexible for future modifications.

This allows the callers of urljoin and urlparse to add guaranteed scheme classes to the url regardless of the actual scheme, which may not be in the default uses_* lists of schemes. This call-time behavior is done through an optional parameter that preserves backwards compatibility. A test case is added for this, and requires the change present in test_urlparse.checkJoin.

github-actions · 2022-02-10T00:06:50Z

This PR is stale because it has been open for 30 days with no activity.

MaxwellDupre

Could you add info to docs Please?
Otherwise how will users know how to use or that it exists?

oldaccountdeadname · 2022-02-26T18:54:48Z

Could you add info to docs Please?

Ah, definitely, I totally forgot to do that - I just pushed a draft of some docs (e1082f8). Thanks for pointing that out!

This functionality was exposed in 53c6ccc.

oldaccountdeadname · 2022-02-26T21:42:29Z

Ah, CI was failing due to my editor inserting tabs - should be fixed. The docs commit is now f9b59dd.

It looks like CI expects this when building documentation.

oldaccountdeadname · 2022-03-10T17:25:01Z

@orsenthil - sorry for the extra email/ping, but would you be able to give this a review when you've got some spare time? It's been sitting stale for roughly a month now. thanks!

orsenthil · 2022-03-12T02:13:45Z

@lincolnauster - sure, I will review.

urljoin will not treat `..` as moving up one directory rather than moving up one file, thus causing the doctests to fail due to a missing trailing slash. Both changes are of the form: http://example.org/post/x -> http://example.org/post/x/ Additionally, the my-protocol example's expected output had the wrong scheme.

oldaccountdeadname · 2022-03-12T18:34:53Z

sigh - code was right, docs were wrong.

Stupid question, but I couldn't find this in the devguide. How do I actually run the doctests on my local checkout? I was performing them manually in a shell but evidently I accidentally corrected them while typing them in.

I'm running this in Doc/:

gmake doctest PYTHON=../python SPHINXOPTS="-j24 --keep-going"

...and I'm getting a ton of errors from code I haven't touched. (A bunch of stuff in the ast module, _tkinter wasn't found, etc.) Is this a misconfiguration on my part? How can I actually run doctests?

Also, I pushed a fix for the current cause of failure. Would it be helpful to squash/rebase it into the original doc commit (f9b59dd) and force-push? Thanks so much!

Minor style things: + _scheme_classes' docstring's summary was made explicit. + _scheme_classes was prepended with and followed by two newlines.

JelleZijlstra · 2022-03-29T16:03:22Z

Doc/library/urllib.parse.rst

@@ -543,6 +555,53 @@ operating on :class:`bytes` or :class:`bytearray` objects:

   .. versionadded:: 3.2

+Special URL Behaviors and Scheme Classes


The name "class" is confusing to me, because it makes me think of a class statement.

Also, why not just add three boolean parameters to urlparse and urljoin? That should make the behavior simpler to use for users.

See also my alternate proposal for a dedicated function on the ticket.
(Fits with the API design guideline of avoiding a boolean param that changes behaviour — I forget the exact phrasing and origin of that)

@JelleZijlstra Three boolean parameters would be a pain. re.match, re.search, etc., use an options parameter to collect all the flags in one.

Why would they be a pain? As a user I'd much rather write use_relative=True than look up some separate flags enum.

Likewise, I am not sure that ~~a bitfield~~ integer flag is the best thing for a regular Python API. The re module had a backward compat concern that doesn’t apply here. But (sorry to repeat my opinion) I am not in favour of piecemeal control, I would rather have a universal parsing function that just implements the universal resource identifier spec :)

@merwok (It's not an integer, that would be IntFlag)

re the universal parsing function -- how would that differ from the proposed additions to urlparse.urlparse?

See ticket:

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 compat for urllib is always a concern; someone said at the time that it could be good to have a new module for modern, generic parsing, but that hasn’t happened. Maybe a new parse function, or new parameter to the existing one, could be easier to add.

So I don’t want to have to pass parameters to request standard parsing for this or that component, I only want one function that forgets the special registries that urllib.parse relies on and just parses a well-formed URI into the universal components (scheme host path etc).

So I don’t want to have to pass parameters to request standard parsing for this or that component, I only want one function that forgets the special registries that urllib.parse relies on and just parses a well-formed URI into the universal components (scheme host path etc).

With the currently pushed code, this would be a one line lambda:

from urllib.parse import SchemeFlag, urlparse parse_standardized = lambda url: urlparse(url, flags=SchemeFlag.NETLOC | SchemeFlag.RELATIVE | SchemeFlag.PARAMS)

Is this worth adding to the PR? I imagine it could be done more extremely (i.e., completely redefine the behavior of urlparse), but would backwards compat not be a concern?

No, we should not redefine the behaviour 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 separate flags to pick and choose parts of standard parsing.

@merwok - added comments to issue; discussion here should be about this PR, discussion about competing PRs (even if the other PRs haven't been written yet ;) should be on the issue tracker.

JelleZijlstra · 2022-03-29T16:03:56Z

Lib/urllib/parse.py

+describe methods for URL resolution, usually by scheme. These resolution classes
+determine, namely, whether a scheme supports, respectively, relative addressing,
+preserving the netloc (domain name), and preserving the parameters."""
+SchemeClass = Enum('SchemeClass', 'RELATIVE NETLOC PARAMS')


Better to use a class statement so the docstring can actually be a docstring.

JelleZijlstra · 2022-03-29T16:05:12Z

Lib/urllib/parse.py

@@ -363,7 +394,7 @@ def _fix_result_transcoding():
 _fix_result_transcoding()
 del _fix_result_transcoding

-def urlparse(url, scheme='', allow_fragments=True):
+def urlparse(url, scheme='', allow_fragments=True, classes=set()):


Avoid mutable defaults, an empty iterable works well. (There are other cases of this throughout the diff.)

Suggested change

def urlparse(url, scheme='', allow_fragments=True, classes=set()):

def urlparse(url, scheme='', allow_fragments=True, classes=()):

@JelleZijlstra using SchemeFlag() creates an immutable default.

I was referring to the original code that used sets, not to your flags suggestion.

ethanfurman

I think SchemeFlag works better than SchemeClass. Either way, use an enum.Flag for it, and consider using __repr__ similar to the one in re.RegexFlag.

ethanfurman · 2022-03-29T15:44:29Z

Lib/urllib/parse.py

@@ -38,13 +39,19 @@
           "urlsplit", "urlunsplit", "urlencode", "parse_qs",
           "parse_qsl", "quote", "quote_plus", "quote_from_bytes",
           "unquote", "unquote_plus", "unquote_to_bytes",
-           "DefragResult", "ParseResult", "SplitResult",
+           "DefragResult", "ParseResult", "SplitResult", "SchemeClass",


Following the example of re.RegexFlag, name this SchemeFlag. Also, use enum.Flag instead of enum.Enum.

ethanfurman · 2022-03-29T15:45:11Z

Lib/urllib/parse.py

+describe methods for URL resolution, usually by scheme. These resolution classes
+determine, namely, whether a scheme supports, respectively, relative addressing,
+preserving the netloc (domain name), and preserving the parameters."""
+SchemeClass = Enum('SchemeClass', 'RELATIVE NETLOC PARAMS')


SchemeFlag

ethanfurman · 2022-03-29T15:46:38Z

Lib/urllib/parse.py

@@ -60,6 +67,30 @@
               'https', 'shttp', 'rtsp', 'rtspu', 'sip', 'sips',
               'mms', 'sftp', 'tel']

+
+def _scheme_classes(scheme, overrides=set()):


overrides should be options or flags. (re.search uses flags)

Lib/urllib/parse.py

ethanfurman · 2022-03-29T15:56:03Z

Lib/urllib/parse.py

@@ -386,7 +417,8 @@ def urlparse(url, scheme='', allow_fragments=True):
    url, scheme, _coerce_result = _coerce_args(url, scheme)
    splitresult = urlsplit(url, scheme, allow_fragments)
    scheme, netloc, url, query, fragment = splitresult
-    if scheme in uses_params and ';' in url:
+    scheme_classes = _scheme_classes(scheme, overrides=classes)


_scheme_classes(scheme, overrides=classes) --> _scheme_classes(scheme, flags)

ethanfurman · 2022-03-29T16:05:15Z

Lib/urllib/parse.py

+    parameter.
+
+    """
+    scheme_classes = set(overrides)


remove line

ethanfurman · 2022-03-29T16:06:19Z

Lib/urllib/parse.py

+    scheme_classes = set(overrides)
+
+    if scheme in uses_relative:
+        scheme_classes.add(SchemeClass.RELATIVE)


options |= SchemeFlag.RELATIVE

same transformation for the next two branches

ethanfurman · 2022-03-29T16:06:44Z

Lib/urllib/parse.py

+    if scheme in uses_params:
+        scheme_classes.add(SchemeClass.PARAMS)
+
+    return scheme_classes


return options

bedevere-bot · 2022-03-29T16:07:03Z

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

oldaccountdeadname · 2022-04-01T00:11:18Z

I have made the requested changes; please review again.

Again, thanks so much for the thorough review, and please tell me if there's anything missing!

bedevere-bot · 2022-04-01T00:11:25Z

Thanks for making the requested changes!

@ethanfurman: please review the changes made to this pull request.

orsenthil · 2022-04-14T22:43:09Z

(copying from #90495) - we can continue discussion here as lot of context is preserved here.

Hi @lincolnauster , I was -1 and was thinking much on introducing a flag with the enum in the parse module.

urlparse(url, scheme='', allow_fragments=True, flags=SchemeFlag(0)):

This API signature is going to confuse people and will be huge blocker for further adoption and change (even if the default arguments are specified). I was thinking how best to mitigate that.

Did we ever consider not going to flag as as parameter?
Any other default for the flag rather than an enum?

If design design required, we can bring it to a wider forum too.

oldaccountdeadname · 2022-04-14T23:26:49Z

Hi @lincolnauster , I was -1 and was thinking much on introducing a flag with the enum in the parse module. urlparse(url, scheme='', allow_fragments=True, flags=SchemeFlag(0)): This API signature is going to confuse people and will be huge blocker for further adoption and change (even if the default arguments are specified). I was thinking how best to mitigate that.

Tbh, I'm not too bothered by the additional complexity in the function signature. As I see it, the complexity is already present in the module's uses_* lists. If those lists align with your goals, you don't need to care about them, but if they don't, you need to deal with that implicit complexity. Documenting it and making it explicit feels like the best path to take, imo.

1 Did we ever consider not going to flag as as parameter?

There were a few alternatives considered in this PR/issue and a few more a few years ago. Correct me if I'm wrong, but I'm not sure anyone is really in favor of the current scheme-based parsing. That said, backwards compat is valuable, so it looks like we're trying to find some way to augment the current parse-behavior selection with a solution that doesn't involve magic strings. Currently, client code can modify the lists that determine the behavior for each scheme, but that's got two problems, as I understand: 1. It's a bag of global state. Who owns what data? What if there are conflicting modifications? This is a pretty good way to cause messy problems. 2. What if we don't know the schemes we're parsing in advance? We'd need a *lot* of interactions with the messy global state, and thus potentially cause a lot of problems. One proposed solution was formalizing that global state into a global registry, which would reduce the impact of the above problems, but not fully solve them. It's certainly a simpler solution, but it also feels harder to use in non-trivial cases. Some form of per-parse/join context seems to be required to address the above issues and keep compat.

2 Any other default for the flag rather than an enum?

I'm not sure what you mean by that. Could you explain further?

If design design required, we can bring it to a wider forum too.

This seems like a good idea if necessary. Thanks for all the thoughts!

gpshead

I agree with Senthil about the API growing something unobvious. If we add a parameter, it should be keyword only and well named to indicate that it is unusual to provide it. I'd also set its default value to None rather than introducing the casual user to a new concept (SchemeFlag).

The name flags= is probably not sufficient. Something more wordy like behavior_overrides= would communicate better that these are not necessary in most cases as reasonable default behaviors exist. Similarly the name SchemeFlags doesn't necessarily communicate the right thing when seen in code as it technically has nothing to do with a scheme itself. Perhaps something like ParseBehaviors?

gpshead · 2022-04-14T23:22:48Z

Doc/library/urllib.parse.rst

-      ParseResult(scheme='http', netloc='docs.python.org:80',
-                  path='/3/library/urllib.parse.html', params='',
-                  query='highlight=params', fragment='url-parsing')
+      ParseResult(scheme='http', netloc='docs.python.org:80', path='/3/library/urllib.parse.html', params='', query='highlight=params', fragment='url-parsing')


do not reformat doctest examples. these were formatted to be narrow to avoid horizontal scrollbars in documentation on most common displays and to keep the .rst itself <80 columns when possible.

reformatting is unrelated to the change at hand and distracts from the actual change.

Restoring the original formatting causes the doctest to fail, I should've broken that out into a separate and clear commit... I'm doctesting with .python -m doctest. Is that wrong, or is there some other way I can keep the old linebreaks?

@gpshead re behavior_overrides vs flags: aren't flags usually behavior overrides? ssl, socket, _pydecimal, _osx_support, and re all use flags, while doctest uses compileflags, _pyio use dec_flags, and subprocess uses creationflags.

My first choice here would be a simple flags, and it should be easily understood that the flags given will modify the parsing behavior of urlparse. Would it be more precise to call it uri_flags? At any rate, behavior_overrides is no less generic and much more verbose than flags.

gpshead · 2022-04-14T23:25:11Z

Doc/library/urllib.parse.rst

@@ -348,19 +349,22 @@ or on combining URL components into a URL string.
   with an empty query; the RFC states that these are equivalent).


-.. function:: urljoin(base, url, allow_fragments=True)
+.. function:: urljoin(base, url, allow_fragments=True, classes=SchemeFlag(0))


Why is this called classes here and flags above? Consistency is important. These should also be made keyword only arguments.

I forgot to update after renaming from classes to flags. I'll change it over to behavior_overrides.

gpshead · 2022-04-14T23:28:09Z

Lib/urllib/parse.py

@@ -39,12 +40,35 @@
           "parse_qsl", "quote", "quote_plus", "quote_from_bytes",
           "unquote", "unquote_plus", "unquote_to_bytes",
           "DefragResult", "ParseResult", "SplitResult",
+           "SchemeFlag", "RELATIVE", "NETLOC", "PARAMS", "UNIVERSAL",


Lets not pollute __all__ with the CONSTANT_NAMES. People shouldn't really use from urllib.parse import * but if they do they shouldn't get these, just SchemeFlag.

@ethanfurman thoughts? I remember you suggested that these should be exported as such for code like

urlparse(uri_string, flags=UNIVERSAL)

or similar. I'm fine either way, but do agree that the namespace would be cleaner were the flags not exported individually.

Putting them in globals() is not for the from ... import * case, since, as @gpshead said, folks should not be doing that; putting them in globals() is to enable urlparse.RELATIVE usage, much like we have re.IGNORECASE and not re.RegexFlag.IGNORECASE.

Lib/urllib/parse.py

gpshead · 2022-04-14T23:34:55Z

Lib/test/test_urlparse.py

@@ -417,6 +417,11 @@ def test_urljoins(self):
        self.checkJoin('svn+ssh://pathtorepo/dir1', 'dir2', 'svn+ssh://pathtorepo/dir2')
        self.checkJoin('ws://a/b','g','ws://a/g')
        self.checkJoin('wss://a/b','g','wss://a/g')
+        self.checkJoin(


make these new SchemeFlag specific test methods instead of appending to an existing long one.

gpshead · 2022-04-14T23:35:21Z

Lib/test/test_urlparse.py

+        self.checkJoin(
+            'nonsensebase://net.loc/url/', '..',
+            'nonsensebase://net.loc/',
+            flags=(urllib.parse.SchemeFlag.RELATIVE | urllib.parse.SchemeFlag.NETLOC),


add more test cases that explicitly cover PARAMS and UNIVERSAL behaviors.

gpshead · 2022-04-14T23:36:28Z

Lib/urllib/parse.py

@@ -363,7 +408,7 @@ def _fix_result_transcoding():
 _fix_result_transcoding()
 del _fix_result_transcoding

-def urlparse(url, scheme='', allow_fragments=True):
+def urlparse(url, scheme='', allow_fragments=True, flags=SchemeFlag(0)):


what does the 0 mean?

@gpshead Somewhere I thought you said it should be flags=None instead -- I agree.

None is used - 677ed1aac3.

gpshead · 2022-04-14T23:42:27Z

Lib/urllib/parse.py

    """Join a base URL and a possibly relative URL to form an absolute
-    interpretation of the latter."""
+    interpretation of the latter. Some logic may be enabled by setting
+    the classes variable."""


I also suggest making the new parameter be keyword only.

bedevere-bot · 2022-04-14T23:51:05Z

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

oldaccountdeadname · 2022-04-21T01:37:52Z

Hi, sorry for getting back to this late, and thanks for all the feedback.

I agree with Senthil about the API growing something unobvious. If we add a parameter, it should be keyword only and well named to indicate that it is unusual to provide it. I'd also set its default value to None rather than introducing the casual user to a new concept (SchemeFlag).

The name flags= is probably not sufficient. Something more wordy like behavior_overrides= would communicate better that these are not necessary in most cases as reasonable default behaviors exist. Similarly the name SchemeFlags doesn't necessarily communicate the right thing when seen in code as it technically has nothing to do with a scheme itself. Perhaps something like ParseBehaviors?

Agreed, I'll push these API clarifications shortly!

Lib/urllib/parse.py

ethanfurman · 2022-05-05T21:08:20Z

Okay, I finally had some time to do a thorough review of the module and, as much as I love enums, I don't think this is the right solution to this problem:

allow_fragments should be part of the enum, but that would just be confusing at this point
specifying NETLOC or RELATIVE to urlparse() does nothing

I like the attempt to unify the three class lists, but I don't think this approach is the best choice for the urlparse module as it exists.

Given that we already have an allow_fragments flag, I think the best path forward is to add an allow_params flag, with a default of False -- or add a separate universal parsing function, as has been suggested earlier.

@lincolnauster Are you interested in converting this PR to one of the two above choices?

ethanfurman

See previous comment.

oldaccountdeadname · 2022-06-12T15:00:10Z

Hi, very sorry for the very late reply - a number of things just stacked up for the past few months.

Okay, I finally had some time to do a thorough review of the module and, as much as I love enums, I don't think this is the right solution to this problem: * allow_fragments should be part of the enum, but that would just be confusing at this point

Agreed in hindsight. There are too many flags for a flag to be comprehensible.

* specifying NETLOC or RELATIVE to urlparse() does nothing

Yeah, the parse/join interface is heterogeneous. Definitely an oversight in the proposed patches as-is (and an oversight in the scheme lists being part of the public API).

I like the attempt to unify the three class lists, but I don't think this approach is the best choice for the urlparse module as it exists. Given that we already have an allow_fragments flag, I think the best path forward is to add an allow_params flag, with a default of False...

What about joining? I believe that when given a string, urljoin will urlparse it. How do we determine the keyword arguments for urlparse in that case? I assume we use additional parameters. What about netloc and relative joining? I believe that gives us this rather unwieldy signature: ```python def urljoin(base, url, allow_fragments=True, allow_params=False, allow_netloc=False, allow_relative=False) ``` Maybe it could be written as the following: ```python def urljoin(base, url, **kwargs) ``` ...where kwargs are passed to urljoin, but I'm still smelling something off here. I'd expect that stacking overrides on overrides on global state is going to get us unpredictable and untestable behavior, no matter how we write out the signature.

-- or add a separate universal parsing function, as has been suggested earlier.

I think I agree on this - universal parsing and joining is probably a good thing. Would it be acceptable to build off the code currently in this PR? That is, simply define some new universal parse and universal join lambdas as proposed above[0], but without exposing the parse flags to the public API? It's kind of messy, but at least it partially moves the mess from the public API to the private implementation. [0]: #30520 (comment) Thanks so much for the detailed discussion, and, again, sorry for such a late response :)

oldaccountdeadname · 2022-10-11T08:22:29Z

CI looks like it's running, it's red only because there's a requested change.

I believe there was an issue with the previous push during the check of generated files: https://github.com/python/cpython/runs/5747980058

oldaccountdeadname · 2022-10-11T09:19:22Z

Hi, very sorry for the very late reply - a number of things just stacked up for the past few months.

Okay, I finally had some time to do a thorough review of the module and, as much as I love enums, I don't think this is the right solution to this problem: * allow_fragments should be part of the enum, but that would just be confusing at this point

Agreed in hindsight. There are too many flags for a flag to be comprehensible.

* specifying NETLOC or RELATIVE to urlparse() does nothing

Yeah, the parse/join interface is heterogeneous. Definitely an oversight in the proposed patches as-is (and an oversight in the scheme lists being part of the public API).

I like the attempt to unify the three class lists, but I don't think this approach is the best choice for the urlparse module as it exists. Given that we already have an allow_fragments flag, I think the best path forward is to add an allow_params flag, with a default of False...

What about joining? I believe that when given a string, urljoin will urlparse it. How do we determine the keyword arguments for urlparse in that case? I assume we use additional parameters. What about netloc and relative joining? I believe that gives us this rather unwieldy signature: ```python def urljoin(base, url, allow_fragments=True, allow_params=False, allow_netloc=False, allow_relative=False) ``` Maybe it could be written as the following: ```python def urljoin(base, url, **kwargs) ``` ...where kwargs are passed to urljoin, but I'm still smelling something off here. I'd expect that stacking overrides on overrides on global state is going to get us unpredictable and untestable behavior, no matter how we write out the signature.

-- or add a separate universal parsing function, as has been suggested earlier.

I think I agree on this - universal parsing and joining is probably a good thing. Would it be acceptable to build off the code currently in this PR? That is, simply define some new universal parse and universal join lambdas as proposed above[0], but without exposing the parse flags to the public API? It's kind of messy, but at least it partially moves the mess from the public API to the private implementation. [0]: #30520 (comment) Thanks so much for the detailed discussion, and, again, sorry for such a late response :)

orsenthil · 2023-04-21T01:45:07Z

I think this change is stale now. We really do not want to introduce additional complexity to the parsing here, at least many changes in one go. I am closing this request, and we can reopen it to add individual changes (minor refactors in a planned manner) if we want a generic solution. Current diff can introduce complexity that many reviewers have observed above.

Thank you for your contribution.

the-knights-who-say-ni added the CLA signed label Jan 10, 2022

bedevere-bot added the awaiting review label Jan 10, 2022

oldaccountdeadname added 2 commits January 10, 2022 14:57

oldaccountdeadname force-pushed the urllib-custom-schemes branch from 627b732 to 53c6ccc Compare January 10, 2022 21:57

📜🤖 Added by blurb_it.

41d3b58

github-actions bot added the stale Stale PR or inactive for long period of time. label Feb 10, 2022

orsenthil self-requested a review February 11, 2022 05:57

MaxwellDupre suggested changes Feb 26, 2022

View reviewed changes

bedevere-bot added awaiting core review and removed awaiting review labels Feb 26, 2022

bpo-46337: Fix grammar of doc comment.

eee880c

bpo-46337: document SchemeClass behavior

f9b59dd

This functionality was exposed in 53c6ccc.

oldaccountdeadname force-pushed the urllib-custom-schemes branch from e1082f8 to f9b59dd Compare February 26, 2022 21:41

add newline to end of news file

1691a1e

It looks like CI expects this when building documentation.

orsenthil self-assigned this Mar 12, 2022

oldaccountdeadname added 2 commits March 11, 2022 22:07

bpo-46337: fix doctest formatting

c7ae936

oldaccountdeadname and others added 2 commits March 13, 2022 01:09

bpo-43677: fixup PEP 8 style

c07600c

Minor style things: + _scheme_classes' docstring's summary was made explicit. + _scheme_classes was prepended with and followed by two newlines.

Merge branch 'main' into urllib-custom-schemes

07a8576

JelleZijlstra reviewed Mar 29, 2022

View reviewed changes

ethanfurman requested changes Mar 29, 2022

View reviewed changes

bedevere-bot removed the awaiting core review label Mar 29, 2022

oldaccountdeadname added 2 commits March 31, 2022 16:42

urllib: expose enums SchemeFlag variants directly

9d7cfb5

urllib: add UNIVERSAL SchemeFlag

81d3414

bedevere-bot added awaiting change review and removed awaiting changes labels Apr 1, 2022

bedevere-bot requested a review from ethanfurman April 1, 2022 00:11

lincolnauster mannequin mentioned this pull request Apr 14, 2022

urllib.parse: Allow more flexibility in schemes and URL resolution behavior #90495

Closed

orsenthil requested a review from gpshead April 14, 2022 22:43

gpshead requested changes Apr 14, 2022

View reviewed changes

bedevere-bot removed the awaiting change review label Apr 14, 2022

bedevere-bot added the awaiting changes label Apr 14, 2022

use None rather than SchemeFlag in public API

677ed1a

oldaccountdeadname added 4 commits April 20, 2022 19:53

do not import from enum

0ec4a4e

doc: correct urljoin signature

b25e0e8

make flags parameter keyword-only

2123ad7

s/classes/flags

9f50dfb

merwok reviewed Apr 21, 2022

View reviewed changes

Lib/urllib/parse.py Show resolved Hide resolved

ethanfurman requested changes May 5, 2022

View reviewed changes

ezio-melotti removed the CLA signed label Jul 13, 2022

orsenthil closed this Apr 21, 2023

		@@ -543,6 +555,53 @@ operating on :class:`bytes` or :class:`bytearray` objects:

		.. versionadded:: 3.2

		Special URL Behaviors and Scheme Classes

	def urlparse(url, scheme='', allow_fragments=True, classes=set()):
	def urlparse(url, scheme='', allow_fragments=True, classes=()):

bpo-46337: Urllib.parse scheme-specific behavior without reliance on URL scheme #30520

bpo-46337: Urllib.parse scheme-specific behavior without reliance on URL scheme #30520

Conversation

oldaccountdeadname commented Jan 10, 2022 • edited by bedevere-bot Loading

github-actions bot commented Feb 10, 2022

MaxwellDupre left a comment

Choose a reason for hiding this comment

oldaccountdeadname commented Feb 26, 2022 via email

oldaccountdeadname commented Feb 26, 2022

oldaccountdeadname commented Mar 10, 2022

orsenthil commented Mar 12, 2022

oldaccountdeadname commented Mar 12, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

merwok Mar 29, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ethanfurman left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bedevere-bot commented Mar 29, 2022

oldaccountdeadname commented Apr 1, 2022

bedevere-bot commented Apr 1, 2022

orsenthil commented Apr 14, 2022

oldaccountdeadname commented Apr 14, 2022 via email

gpshead left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ethanfurman Apr 21, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bedevere-bot commented Apr 14, 2022

oldaccountdeadname commented Apr 21, 2022

ethanfurman commented May 5, 2022

ethanfurman left a comment

Choose a reason for hiding this comment

oldaccountdeadname commented Jun 12, 2022 via email

oldaccountdeadname commented Oct 11, 2022 via email

oldaccountdeadname commented Oct 11, 2022 via email

orsenthil commented Apr 21, 2023

oldaccountdeadname commented Jan 10, 2022 •

edited by bedevere-bot

Loading

merwok Mar 29, 2022 •

edited

Loading

ethanfurman Apr 21, 2022 •

edited

Loading