[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Jacob Walls added the comment: Well, now I've looked at the CPython test failure more closely, and it's in `test.test_venv.EnsurePipTest` where we just download latest pip. Their release cadence suggests a new release in July, about 2-4 weeks from now. So I'll wait on adding the Deprecation

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Jacob Walls added the comment: Both this ticket and #19094 started from one method in urllib.parse and then generalized a proposal for the rest of the submodule to move away from duck-typing and to instead raise TypeErrors (or at least some error) for invalid types. The attached PR does that

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Change by Jacob Walls : -- nosy: +jacobtylerwalls nosy_count: 7.0 -> 8.0 pull_requests: +25291 pull_request: https://github.com/python/cpython/pull/26687 ___ Python tracker ___

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Serhiy Storchaka added the comment: Thank you Luiz for your testing. > __main__:1: DeprecationWarning: Use of '' is deprecated It is bad that a warning is emitted for default value. > Will bytes be deprecated if used as a default_schema? No, only using empty bytes schema with string url is de

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Antti Haapala added the comment: I do not believe there is code that would depend on `urlparse(urlstring={})` *not* throwing an error, since `{}` obviously is neither a URL, nor a string. Further down the documentation explicitly states that > The URL parsing functions were originally designed

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Senthil Kumaran added the comment: Serhiy: I left review comments on the patch too. I agree to "tightening" of the input arg type in these urlparse functions. Before we for the next version, I think, it will be helpful to enumerate the behavior for wrong arg types for these functions that yo

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Luiz Poleto added the comment: As for urlparse_empty_bad_arg_disallow.patch, I didn't go too deep into testing it but I found that calling urlparse with different non-str args are producing different results: urlparse({}) TypeError: unhashable type: 'slice' urlparse([]) AttributeError: 'list'

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Martin Panter added the comment: Regarding urlparse(b'', ''). Currently the second parameter is “scheme”, which is documented as being an empty text string by default. If we deprecate this, we should update the documentation. -- ___ Python tracker

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Luiz Poleto added the comment: I am seeing some results when running urlparse with patch urlparse_empty_bad_arg_deprecation2.patch applied: >>> urllib.parse.urlparse({}) __main__:1: DeprecationWarning: Use of {} is deprecated __main__:1: DeprecationWarning: Use of '' is deprecated ParseResultBy

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Serhiy Storchaka added the comment: Updated patch addresses Martin's comment. -- Added file: http://bugs.python.org/file42607/urlparse_empty_bad_arg_deprecation2.patch ___ Python tracker __

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Changes by Anish Shah : -- nosy: -anish.shah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Serhiy Storchaka added the comment: And here is simpler patch that just disallows bad arguments without deprecation. -- Added file: http://bugs.python.org/file42602/urlparse_empty_bad_arg_disallow.patch ___ Python tracker

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Serhiy Storchaka added the comment: Here is a patch that deprecates empty non-str and non-decodable arguments for urlparse, urlsplit, urlunparse, urlunsplit, urldefrag, and parse_qsl. -- Added file: http://bugs.python.org/file42600/urlparse_empty_bad_arg_deprecation.patch

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Martin Panter added the comment: Luiz: Your _36 patch looks like it adds an unconditional warning whenever urlparse() is called, but I would have expected it to depend on the type of the “url” parameter. There are related functions that seem to accept false values like None in Python 3, but n

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Serhiy Storchaka added the comment: `x != ''` emits BytesWarning if x is bytes. 'encode' attribute is not needed for URL parsing. any() is slower that a `for` loop. I would suggest to look at efficient os.path implementations. -- nosy: +serhiy.storchaka ___

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Luiz Poleto added the comment: As discussed on the Mentors list, the attached patch (issue22234_37.patch) changes the urlparse function to handle non-str and non-bytes arguments and adds a new test case for it. -- Added file: http://bugs.python.org/file42592/issue22234_37.patch __

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Luiz Poleto added the comment: As discussed on the Mentors list, the attached patch (issue22234_36.patch) includes the deprecation warning (and related test) on the urlparse function. -- keywords: +patch versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file42591/issu

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

R. David Murray added the comment: I just posted about this on the mentors list, where someone brought this issue up with a question about our policy on type checking. The short version is the better (preserves duck-typing) and more backward compatibile fix is to change the test to be x !

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Changes by Luiz Poleto : -- nosy: +luiz.poleto ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Changes by Anish Shah : -- nosy: +anish.shah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Antti Haapala added the comment: I believe `urlparse` should throw a `TypeError` if not isinstance(url, (str, bytes)) -- ___ Python tracker ___ _

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Antti Haapala added the comment: On Python 2.7 urlparse.urlparse, parsing None, () or 0 will throw AttributeError because these classes do not have any 'find' method. [] has the find method, but will fail with TypeError, because the built-in caching requires that the input be hashable. --

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Changes by Martin Panter : -- nosy: +vadmium ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Changes by Demian Brecht : -- nosy: +demian.brecht ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Changes by Berker Peksag : -- nosy: +orsenthil ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

New submission from Antti Haapala: Because of "if x else ''" in _decode_args (http://hg.python.org/cpython/file/3.4/Lib/urllib/parse.py#l96), urllib.parse.urlparse accepts any falsy value as an url, returning a ParseResultBytes with all members set to empty bytestrings. Thus you get: >>>