[python-committers] Re: A urlparse regression in minor version

2020-02-16 Thread Ned Deily 
On Feb 15, 2020, at 09:00, Senthil Kumaran  wrote:
> As we have to a decision here, my vote is to revert the patch in 3.8.2 and 
> 3.7.7
> I have gone back-and-forth with this thinking, and it seems revert might 
> address some definite complaints we have got.
> The problem is contained to single version, and users can upgrade to the next 
> one.

> On Fri, Feb 14, 2020 at 8:14 AM Łukasz Langa  wrote:
>> Ned, what are you doing with this for 3.7.7? Reverting?

Ugh!

As others have noted, urlparse is a big can of worms.  I am certainly not a 
subject expert but, from some investigation and thinking about it, it seems to 
me that we kinda brought this on ourselves by allowing the scheme part (e.g. 
"https:" or "ftp:" or "any-old-scheme:" etc) of the urlstring parameter to be 
optional:

urllib.parse.urlparse(urlstring, scheme='', allow_fragments=True)

therby introducing the ambiguity of whether a string like "localhost:80" 
denotes a relative url with a user-defined scheme of "localhost" and a path of 
"80" (as it now does with the changes for bpo-27657 introduced in 3.8.1 and 
3.7.6):

>>> urlparse("localhost:80")
ParseResult(scheme='localhost', netloc='', path='80', params='', query='', 
fragment='')

or denotes a relative url with no scheme and a path of "localhost:80" (as 
happened in previous releases):

>>> urlparse("localhost:80")
ParseResult(scheme='', netloc='', path='localhost:80', params='', query='', 
fragment='')

With an explicit scheme, in either case you get what you would expect - an 
absolute url:

>>> urlparse("http://localhost:80";)
ParseResult(scheme='http', netloc='localhost:80', path='', params='', query='', 
fragment='')

AFAICT the intent of the original RFCs was to require an explicit scheme in a 
urlstring, thus avoiding any ambiguity.  But the now universal practice of web 
browsers supplying a default http: or https: scheme for (partial) urls typed 
into a location bar has understandably changed user expectations to often be 
that schemes are optional when the scheme is clear in context.

So it seems to me that there is no one obviously correct behavior here.  
Judging from the comments and the reports of broken packages, many users are 
clearly used to using urlparse with schemeless urlstrings even if they aren't 
truly conformant URLs and even with the at first glance unintuitive way they 
were parsed by urlparse; for example, there is this snippet in the third-party 
requests package:

# urlparse is a finicky beast, and sometimes decides that there isn't a
# netloc present. Assume that it's being over-cautious, and switch netloc
# and path if urlparse decided there was no netloc.
if not netloc:
netloc, path = path, netloc

OTOH, there are also undoubtedly users who want a urlparser that more strictly 
parses schemeless URLs, which is now the behavior as of 3.8.1 and 3.7.6, again, 
even if the new behavior is also unintuitive.

I don't see how we can satisfy both use cases without changing the API somehow. 
 And there may be other use cases.

The good news is that, AFAICT from a quick survey, the change didn't affect 
urllib.urlopen or thrid-party urllib3 or requests.  But from the "me-toos" on 
the bpo issue and the PR, it's clear that we broke stuff downstream and it 
seems that most of those users are waiting for a resolution from us and likely 
would prefer to stick to the previous behavior.

So my take is that we should revert the 3.7 changes (bpo-27657 / PR 16837 / 
82b5f6b16e051f8a2ac6e87ba86b082fa1c4a77f ).  Senthil, please go ahead and do so 
for the 3.7 branch.  Thanks!

While it's not my call, I think we should also revert for 3.8.2.

For 3.9.0, I recommend we reconsider this change (temporarily reverting it) and 
consider whether an API change to accommodate the various use cases would be 
better; perhaps something like adding a new parameter to urlparse to indicate 
whether urlstrings should be parsed like webbrowser "urls" (and defining 
exactly what that means) and also review the many remaining open urlparse bpo 
issues to look for commonalities.  (Perhaps that could be a post-3.9 GsoC 
project?)

Thoughts?

In any case, ugh!

--
  Ned Deily
  [email protected] -- []
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/LSQG3M7G4WB7LNOSBU52AMAKB7LBD7WT/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: A urlparse regression in minor version

2020-02-16 Thread Senthil Kumaran 
On Sun, Feb 16, 2020 at 2:20 AM Ned Deily  wrote:

>
>
> For 3.9.0, I recommend we reconsider this change (temporarily reverting
> it) and consider whether an API change to accommodate the various use cases
> would be better
>

For 3.9. - I am ready to defend the patch even at the cost of the breaking
of the parsing of undefined behavior.  We should keep it. The patch
simplifies a lot of corner cases and fixes the reported bugs. We don't
guarantee backward compatibility between major versions, so I assume users
will be careful when relying upon this undefined behavior and will take
corrective action on their side before upgrading to 3.9.

We want patch releases to be backward compatible. That was the
user-complaint.

Thanks,
Senthil
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/SQE6TKOYZKEFGWMUHU5RCHRVWJ27TIQV/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: A urlparse regression in minor version

2020-02-16 Thread Antoine Pitrou 

FWIW, I agree with Senthil here.  A slight behaviour change in 3.9 is
fine, especially in an area where the "right" semantics are not
immediately obvious.  What we want to avoid is breaking behaviour
changes in bugfix releases.

Regards

Antoine.


Le 16/02/2020 à 13:13, Senthil Kumaran a écrit :
> 
> On Sun, Feb 16, 2020 at 2:20 AM Ned Deily  > wrote:
> 
> 
> 
> For 3.9.0, I recommend we reconsider this change (temporarily
> reverting it) and consider whether an API change to accommodate the
> various use cases would be better
> 
> 
> For 3.9. - I am ready to defend the patch even at the cost of the
> breaking of the parsing of undefined behavior.  We should keep it. The
> patch simplifies a lot of corner cases and fixes the reported bugs. We
> don't guarantee backward compatibility between major versions, so I
> assume users will be careful when relying upon this undefined behavior
> and will take corrective action on their side before upgrading to 3.9.
> 
> We want patch releases to be backward compatible. That was the
> user-complaint.
> 
> Thanks,
> Senthil
> 
> 
> 
> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/SQE6TKOYZKEFGWMUHU5RCHRVWJ27TIQV/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/P6N7GWW5RQ66467NXYJPHV6JKBY4QM27/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: A urlparse regression in minor version

2020-02-16 Thread Ned Deily 
On Feb 16, 2020, at 07:21, Antoine Pitrou  wrote:
> FWIW, I agree with Senthil here.  A slight behaviour change in 3.9 is
> fine, especially in an area where the "right" semantics are not
> immediately obvious.  What we want to avoid is breaking behaviour
> changes in bugfix releases.

I agree totally that we don't want to break behavior in bugfix releases and I 
have no problem with making breaking changes in feature releases (3.9.0) as 
warranted.

My point was that, after looking at this a bit, it seems to me that making this 
change does not address some of the underlying problems with the urlparse API 
and that it makes things *much* worse for the many users who are understandably 
expecting urlparse to sanely handle schemaless urlstrings, the most commonly 
seen urls format today.
 
Note that we strongly imply that we sanely handle them by offering the 
"scheme=" paramater to urlparse.  Another example: prior to 3.7.6 and 3.8.1:

>>> urlparse("www.google.com:8080", scheme="http")
ParseResult(scheme='http', netloc='', path='www.google.com:8080', params='', 
query='', fragment='')

That isn't what users would expect; what they would expect is how things work 
with an explicit scheme (note the swapping of netloc and path).

>>> urlparse("https://www.google.com:8080";, scheme="http")
ParseResult(scheme='https', netloc='www.google.com:8080', path='', params='', 
query='', fragment='')

But at least there is a relatively simple workaround that users have discovered 
as witnessed by the requests code snippet I cited earlier: use the path field 
if netloc is empty.

Now with the change in 3.8.1 and 3.7.6, the behavior is very different and 
pretty useless even with an explicit scheme="http" parameter:

>>> urlparse("www.google.com:8080", scheme="http")
ParseResult(scheme='www.google.com', netloc='', path='8080', params='', 
query='', fragment='')

i.e. www.google.com://8000

While that may be what strict adherence to the RFC dictates, most users aren't 
going to expect or desire results like that.  So while the change may fix some 
cases, it's only making matters worse.  What kind of workaroud do you use for 
that result?

In another open issue concerning a different urlparse issue, Victor noted that 
(4 months ago) "there are 124 open issues with "urllib" in their title and 12 
open issues with "urlparse" in their title" and hit a bit of a dead end with a 
proposed fix.

https://bugs.python.org/issue36338#msg355322

Rather than continuing this change in 3.9 introducing yet another, even more 
unexpected behavior, I think we should first try to address what appears to me 
to be the (a?) root cause issue: urlparse's API is not suited for parsing both 
strictly RFC-compliant URLs (which are clearly not well-understood) *and* 
today's schemeless URLs as have evolved over the years to become the most 
commonly encountered form of URL.  Users want and need both.  The merged change 
makes the previous situation worse, IMHO.


Le 16/02/2020 à 13:13, Senthil Kumaran a écrit :
>> 
>> On Sun, Feb 16, 2020 at 2:20 AM Ned Deily > > wrote:
>> 
>> 
>> 
>>For 3.9.0, I recommend we reconsider this change (temporarily
>>reverting it) and consider whether an API change to accommodate the
>>various use cases would be better
>> 
>> 
>> For 3.9. - I am ready to defend the patch even at the cost of the
>> breaking of the parsing of undefined behavior.  We should keep it. The
>> patch simplifies a lot of corner cases and fixes the reported bugs. We
>> don't guarantee backward compatibility between major versions, so I
>> assume users will be careful when relying upon this undefined behavior
>> and will take corrective action on their side before upgrading to 3.9.
>> 
>> We want patch releases to be backward compatible. That was the
>> user-complaint.
>> 
>> Thanks,
>> Senthil
>> 
>> 
>> 
>> ___
>> python-committers mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/[email protected]/message/SQE6TKOYZKEFGWMUHU5RCHRVWJ27TIQV/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>> 
> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/P6N7GWW5RQ66467NXYJPHV6JKBY4QM27/
> Code of Conduct: https://www.python.org/psf/codeofconduct/

--
  Ned Deily
  [email protected] -- []
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[python-committers] Re: A urlparse regression in minor version

2020-02-16 Thread Senthil Kumaran 
I have created the PRs for the revert in 3.8.2 and 3.7.7

https://github.com/python/cpython/pull/18525 (3.8) - Acceptance definitely
depends on the RM ( Łukasz' s call) and I will support it.
https://github.com/python/cpython/pull/18526 (3.7) - Let this be reverted
only if 3.8 gets reverted.

@Ned -
> Note that we strongly imply that we sanely handle them by offering the
"scheme=" parameter to urlparse.

It is a good idea. I will dig deeper with the help of test cases for 3.8. (
At the moment, given the tests cases the only test case which obviously
fails the expectation in 'localhost:8000')
But it seems that in the bug report, it was discussed and analyzed before
the call was taken to simplify the logic of parsing support.
So, for 3.9 use case, we can revisit this decision separately and i will
account for the points that you have brought up.

If do not end up reverting in 3.8.2 - at the moment, my approach will be to
document the behavior and encourage users to make sure that URL's have a
scheme for the valid parsing behavior between 3.7, 3.8, and 3.9




On Sun, Feb 16, 2020 at 4:21 AM Antoine Pitrou  wrote:

>
> FWIW, I agree with Senthil here.  A slight behaviour change in 3.9 is
> fine, especially in an area where the "right" semantics are not
> immediately obvious.  What we want to avoid is breaking behaviour
> changes in bugfix releases.
>
> Regards
>
> Antoine.
>
>
> Le 16/02/2020 à 13:13, Senthil Kumaran a écrit :
> >
> > On Sun, Feb 16, 2020 at 2:20 AM Ned Deily  > > wrote:
> >
> >
> >
> > For 3.9.0, I recommend we reconsider this change (temporarily
> > reverting it) and consider whether an API change to accommodate the
> > various use cases would be better
> >
> >
> > For 3.9. - I am ready to defend the patch even at the cost of the
> > breaking of the parsing of undefined behavior.  We should keep it. The
> > patch simplifies a lot of corner cases and fixes the reported bugs. We
> > don't guarantee backward compatibility between major versions, so I
> > assume users will be careful when relying upon this undefined behavior
> > and will take corrective action on their side before upgrading to 3.9.
> >
> > We want patch releases to be backward compatible. That was the
> > user-complaint.
> >
> > Thanks,
> > Senthil
> >
> >
> >
> > ___
> > python-committers mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://mail.python.org/mailman3/lists/python-committers.python.org/
> > Message archived at
> https://mail.python.org/archives/list/[email protected]/message/SQE6TKOYZKEFGWMUHU5RCHRVWJ27TIQV/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/P6N7GWW5RQ66467NXYJPHV6JKBY4QM27/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/CVYPD6QL4O6GDEMYWRGWX3SSCBFJ6TYE/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: A urlparse regression in minor version

2020-02-16 Thread Łukasz Langa 
OK, let's revert this for 3.8.2. I will make 3.8.2rc2 with this to highlight 
the revert and get some testing in.

-- 
Best regards,
Łukasz Langa

> On 16 Feb 2020, at 19:31, Senthil Kumaran  wrote:
> 
> 
> I have created the PRs for the revert in 3.8.2 and 3.7.7 
> 
> https://github.com/python/cpython/pull/18525 (3.8) - Acceptance definitely 
> depends on the RM ( Łukasz' s call) and I will support it.
> https://github.com/python/cpython/pull/18526 (3.7) - Let this be reverted 
> only if 3.8 gets reverted.
> 
> @Ned - 
> > Note that we strongly imply that we sanely handle them by offering the 
> > "scheme=" parameter to urlparse. 
> 
> It is a good idea. I will dig deeper with the help of test cases for 3.8. ( 
> At the moment, given the tests cases the only test case which obviously fails 
> the expectation in 'localhost:8000')
> But it seems that in the bug report, it was discussed and analyzed before the 
> call was taken to simplify the logic of parsing support.
> So, for 3.9 use case, we can revisit this decision separately and i will 
> account for the points that you have brought up.
> 
> If do not end up reverting in 3.8.2 - at the moment, my approach will be to 
> document the behavior and encourage users to make sure that URL's have a 
> scheme for the valid parsing behavior between 3.7, 3.8, and 3.9
> 
> 
> 
> 
>> On Sun, Feb 16, 2020 at 4:21 AM Antoine Pitrou  wrote:
>> 
>> FWIW, I agree with Senthil here.  A slight behaviour change in 3.9 is
>> fine, especially in an area where the "right" semantics are not
>> immediately obvious.  What we want to avoid is breaking behaviour
>> changes in bugfix releases.
>> 
>> Regards
>> 
>> Antoine.
>> 
>> 
>> Le 16/02/2020 à 13:13, Senthil Kumaran a écrit :
>> > 
>> > On Sun, Feb 16, 2020 at 2:20 AM Ned Deily > > > wrote:
>> > 
>> > 
>> > 
>> > For 3.9.0, I recommend we reconsider this change (temporarily
>> > reverting it) and consider whether an API change to accommodate the
>> > various use cases would be better
>> > 
>> > 
>> > For 3.9. - I am ready to defend the patch even at the cost of the
>> > breaking of the parsing of undefined behavior.  We should keep it. The
>> > patch simplifies a lot of corner cases and fixes the reported bugs. We
>> > don't guarantee backward compatibility between major versions, so I
>> > assume users will be careful when relying upon this undefined behavior
>> > and will take corrective action on their side before upgrading to 3.9.
>> > 
>> > We want patch releases to be backward compatible. That was the
>> > user-complaint.
>> > 
>> > Thanks,
>> > Senthil
>> > 
>> > 
>> > 
>> > ___
>> > python-committers mailing list -- [email protected]
>> > To unsubscribe send an email to [email protected]
>> > https://mail.python.org/mailman3/lists/python-committers.python.org/
>> > Message archived at 
>> > https://mail.python.org/archives/list/[email protected]/message/SQE6TKOYZKEFGWMUHU5RCHRVWJ27TIQV/
>> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>> > 
>> ___
>> python-committers mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/[email protected]/message/P6N7GWW5RQ66467NXYJPHV6JKBY4QM27/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/CVYPD6QL4O6GDEMYWRGWX3SSCBFJ6TYE/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/OLJL6SIAOYTPZPSEWHLQ33VFHMLSRSQT/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: A urlparse regression in minor version

2020-02-16 Thread Senthil Kumaran 
Thank you all. This is reverted in 3.8.2 and 3.7.7 - with NEWS explaining
the behavior clearly.
For the points that Ned brought up for 3.9, I will continue in the bug
report https://bugs.python.org/issue27657
This discussion can be considered complete and closed.

Thanks for the support.

On Sun, Feb 16, 2020 at 12:13 PM Łukasz Langa  wrote:

> OK, let's revert this for 3.8.2. I will make 3.8.2rc2 with this to
> highlight the revert and get some testing in.
>
> --
> Best regards,
> Łukasz Langa
>
> On 16 Feb 2020, at 19:31, Senthil Kumaran  wrote:
>
> 
> I have created the PRs for the revert in 3.8.2 and 3.7.7
>
> https://github.com/python/cpython/pull/18525 (3.8) - Acceptance
> definitely depends on the RM ( Łukasz' s call) and I will support it.
> https://github.com/python/cpython/pull/18526 (3.7) - Let this be reverted
> only if 3.8 gets reverted.
>
> @Ned -
> > Note that we strongly imply that we sanely handle them by offering the
> "scheme=" parameter to urlparse.
>
> It is a good idea. I will dig deeper with the help of test cases for 3.8.
> ( At the moment, given the tests cases the only test case which obviously
> fails the expectation in 'localhost:8000')
> But it seems that in the bug report, it was discussed and analyzed before
> the call was taken to simplify the logic of parsing support.
> So, for 3.9 use case, we can revisit this decision separately and i will
> account for the points that you have brought up.
>
> If do not end up reverting in 3.8.2 - at the moment, my approach will be
> to document the behavior and encourage users to make sure that URL's have a
> scheme for the valid parsing behavior between 3.7, 3.8, and 3.9
>
>
>
>
> On Sun, Feb 16, 2020 at 4:21 AM Antoine Pitrou  wrote:
>
>>
>> FWIW, I agree with Senthil here.  A slight behaviour change in 3.9 is
>> fine, especially in an area where the "right" semantics are not
>> immediately obvious.  What we want to avoid is breaking behaviour
>> changes in bugfix releases.
>>
>> Regards
>>
>> Antoine.
>>
>>
>> Le 16/02/2020 à 13:13, Senthil Kumaran a écrit :
>> >
>> > On Sun, Feb 16, 2020 at 2:20 AM Ned Deily > > > wrote:
>> >
>> >
>> >
>> > For 3.9.0, I recommend we reconsider this change (temporarily
>> > reverting it) and consider whether an API change to accommodate the
>> > various use cases would be better
>> >
>> >
>> > For 3.9. - I am ready to defend the patch even at the cost of the
>> > breaking of the parsing of undefined behavior.  We should keep it. The
>> > patch simplifies a lot of corner cases and fixes the reported bugs. We
>> > don't guarantee backward compatibility between major versions, so I
>> > assume users will be careful when relying upon this undefined behavior
>> > and will take corrective action on their side before upgrading to 3.9.
>> >
>> > We want patch releases to be backward compatible. That was the
>> > user-complaint.
>> >
>> > Thanks,
>> > Senthil
>> >
>> >
>> >
>> > ___
>> > python-committers mailing list -- [email protected]
>> > To unsubscribe send an email to [email protected]
>> > https://mail.python.org/mailman3/lists/python-committers.python.org/
>> > Message archived at
>> https://mail.python.org/archives/list/[email protected]/message/SQE6TKOYZKEFGWMUHU5RCHRVWJ27TIQV/
>> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>> >
>> ___
>> python-committers mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/[email protected]/message/P6N7GWW5RQ66467NXYJPHV6JKBY4QM27/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/CVYPD6QL4O6GDEMYWRGWX3SSCBFJ6TYE/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/VKWDK4HAOZZSAAXHBLEZ3T3DWE7QH3OP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: A urlparse regression in minor version

2020-02-16 Thread Barry Warsaw 
On Feb 16, 2020, at 10:20, Ned Deily  wrote:

> Rather than continuing this change in 3.9 introducing yet another, even more 
> unexpected behavior, I think we should first try to address what appears to 
> me to be the (a?) root cause issue: urlparse's API is not suited for parsing 
> both strictly RFC-compliant URLs (which are clearly not well-understood) 
> *and* today's schemeless URLs as have evolved over the years to become the 
> most commonly encountered form of URL.  Users want and need both.  The merged 
> change makes the previous situation worse, IMHO.

ISTM that the tension between doing the right thing and keeping backward 
compatibility should be explored through the addition of a new function with 
the intended semantics, or at least a new parameter (keyword-only?) that 
controls the behavior.  I don’t like the latter as much, but if you really want 
to keep a single functional interface, that would be a way to do it.

I don’t agree that it’s obviously okay to introduce a backward incompatible 
default behavior in 3.9.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/3I5Q2PQ4BFJSUFTUIO7ELNE6HIW3QVIK/
Code of Conduct: https://www.python.org/psf/codeofconduct/