[issue1500504] Alternate RFC 3986 compliant URI parsing module
Changes by A.M. Kuchling a...@amk.ca: -- nosy: -akuchling ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
A.M. Kuchling added the comment: Here's a slightly modified version of urischeme.py that can be run under Python 3 and compares its results with urllib.parse, printing out the mismatches. The major differences seem to be 1) urischeme fills in the default port if it's not explicitly provided, e.g. http urls have the port set to 80, 2) the path is returned as '/', not the empty string, for the URL http://host, 3) urllib.parse.urljoin() doesn't get rid of ./ and ../ in URLs. 3) seems like something worth fixing in urllib.parse. The others probably present some backward-compatibility issues. -- nosy: +akuchling Added file: http://bugs.python.org/file32591/urischemes.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Changes by Łukasz Langa luk...@langa.pl: -- nosy: +lukasz.langa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Changes by Ezio Melotti ezio.melo...@gmail.com: -- versions: +Python 3.4 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Éric Araujo mer...@netwok.org added the comment: Sure, adding tests is a no-brainer. Regarding the module, I’m a bit reluctant. I see value in providing low-level building blocks (think OS calls) and high-level utilities for regular use, but here it seems that urllib.parse and urischemes are at the same level. I’m not opposed to the functionality itself—I would like to use a class simply named “URI” (and generally get better names, that is RFC names instead of specific inventions), have components normalization and such goodies—but I think the existing module can get fixes and improvements. I fear the confusion that could be caused by having two modules for the same task, unless you want to propose that the new module deprecate urllib.parse. Senthil, what is your opinion? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Nick Coghlan ncogh...@gmail.com added the comment: Just to be clear, even *I* don't think adding urischemes as it stands is a particularly great idea, and I wrote it. The only reason I haven't closed the issue is because I'd like to see it mined for additional tests in test_urlparse and perhaps even implementation or API enhancements in url.parse first. (The latter becomes a lot more likely if the urischemes implementation passes tests that url.parse fails) I also think, since I wrote this, the various urllib parsing methods were updated to return named tuple instances with properties, so a lot of the awkwardness of extracting partial values went away. (i.e. returning structured objects already raised the level of the urllib APIs from the tuple-of-strings level they used to be sitting at) I do still assert that urischemes is slightly higher level than the current incarnation of similar functionality in urllib.parse. Universal Resource Identifiers are more encompassing than Universal Resource Locators and Universal Resource Names, and the new APIs explicitly deal with both kinds of URI. There are subtle differences in the assumptions you're allowed to make when you may have a URN rather than a URL, so I believe the current module sometimes does the wrong thing when given one of the former. That said, it's been a long time since I've needed to remember the details, so I don't recall exactly where the current module gets URI handling wrong (or at least, did back in 2006). The intro to RFC 3986 is a good place to start in learning the differences though - Sir Tim writes good docs :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Éric Araujo mer...@netwok.org added the comment: Is this still relevant? Can’t the improvements make it into urllib.parse? -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Nick Coghlan ncogh...@gmail.com added the comment: I still like the higher level API concept, although I might not do it exactly as presented here any more. Independently of introducing a new parsing API, it would be worthwhile extracting the parsing tests from the attached module to make sure the *existing* parser can handle them all correctly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Changes by Terry J. Reedy tjre...@udel.edu: -- versions: +Python 3.2 -Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Nick Coghlan ncogh...@gmail.com added the comment: accepted is a little too strong for the current status of this :) I've removed the easy tag as well (making the case for this or something like it in the standard library it going to involve a fair bit of effort - the coding was actually the comparatively easy part). -- keywords: -easy resolution: accepted - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Senthil Kumaran orsent...@gmail.com added the comment: A new way for parsing URI. I have not reviewed it even after saying I would like to, but having the dependency issue resolved, I think it is good to look at it again, especially if it leads some helpful approaches to parsing IRI. -- assignee: - orsenthil dependencies: -URI parsing library resolution: - accepted ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Changes by Senthil orsent...@gmail.com: -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Nick Coghlan ncogh...@gmail.com added the comment: The code itself is no longer the hard part here (hence the easy tag). The problem is the fact that getting something like this into the standard library is a tough sell on python-dev because it isn't really a field tested module, but once people start downloading things from PyPI, they're more likely to go for something like 4Suite rather than a mere URI parsing module. What the issue really needs is someone to champion the benefits of having this in the standard library. Now that it is available, it would also be worth looking at updating the module to use collection.named_tuple instead of creating its own variant of the same thing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Daniel Diniz aja...@gmail.com added the comment: ISTM that gathering the issues where this would help is a good start, but I haven't had the time to do it yet. -- dependencies: +URI parsing library ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Senthil orsent...@gmail.com added the comment: I am willing to review this/work on it. But I wonder if this can be categorized as easy task. 1) Integration to Standard Library will involve compatibility with existing parsing, which will invariably involve certain tweaks (with discussions/buy-in from others). 2) There are other patches which tries to achieve this purpose; consolidation is required. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1500504] Alternate RFC 3986 compliant URI parsing module
Daniel Diniz aja...@gmail.com added the comment: I'll collect open issues that would be solved by this. -- components: +Library (Lib) -None nosy: +ajaksu2 stage: - patch review type: - feature request versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1500504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
