Senthil Kumaran <orsent...@gmail.com> added the comment:
Hello Michael,
Looking a bit deeper into this issue, I don't see that 'x://' and 'x:///y'
qualifies as valid URLS as per RFC 3986. (Well, urlparse has been not strictly
conforming to it, but that is a different issue)
If you look at the section 3. it states the following for validity.
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
In those cases, I would assume that 'x://y', x:/y','x:/','/' as valid URLS, but
not the two examples you mentioned.
For the issue7904, we had just gone by the definition of RFC to make that minor
change and it has resulted in this issue. I looked at the code to see if this
can be addressed, but I see that your examples did not fit in as valid urls.
Do you have any opinions on this?
We can just the test_urlparse.py a little like below, and you might fix the
break your code.
def test_unparse_parse(self):
- for u in ['Python', './Python','x-newscheme://foo.com/stuff']:
+ for u in ['Python',
'./Python','x-newscheme://foo.com/stuff','x://y','x:/y','x:/','/',]:
self.assertEqual(urlparse.urlunsplit(urlparse.urlsplit(u)), u)
self.assertEqual(urlparse.urlunparse(urlparse.urlparse(u)), u)
----------
assignee: -> orsenthil
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8339>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
