[issue8339] urlunparse(urlparse('x://')) now returns 'x:' instead of 'x://'

Senthil Kumaran report at bugs.python.org
Fri Apr 9 20:00:05 CEST 2010

Senthil Kumaran <orsenthil at 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 <report at bugs.python.org>

More information about the Python-bugs-list mailing list