This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author orsenthil
Recipients Michael Glassford, orsenthil, r.david.murray
Date 2010-04-09.18:00:02
SpamBayes Score 1.48431e-06
Marked as misclassified No
Message-id <>
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 a little like below, and you might fix the break your code.

     def test_unparse_parse(self):
-        for u in ['Python', './Python','x-newscheme://']:
+        for u in ['Python', './Python','x-newscheme://','x://y','x:/y','x:/','/',]:
             self.assertEqual(urlparse.urlunsplit(urlparse.urlsplit(u)), u)
             self.assertEqual(urlparse.urlunparse(urlparse.urlparse(u)), u)
Date User Action Args
2010-04-09 18:00:05orsenthilsetrecipients: + orsenthil, r.david.murray, Michael Glassford
2010-04-09 18:00:05orsenthilsetmessageid: <>
2010-04-09 18:00:03orsenthillinkissue8339 messages
2010-04-09 18:00:02orsenthilcreate