Senthil <[EMAIL PROTECTED]> added the comment: I am attaching the modified patch, which addresses the port issue properly and handles 'http:', 'https:' only URLS. Also included the tests for it.
Facundo, I gave sufficient thought on raising an Exception for URLS not staring with '//', and I am -1 for it. As urlparse module is used for handling both absolute URLs as well as relative URLS, this suggestion IMHO, would break the urlparse handling of all relative urls. For e.g, cases which are mentioned in the RFC 1808 (Section 5.1 Normal Examples). The way to inform the users to use '//net_loc' when they want net_loc, would be Docs/Help message (included in the patch) and otherwise urlparse following RFC1808, will treat it as the path. This case may seem absurd when 'www.python.org' is treated as path but perfect for parsing relative urls like just 'a'. More over this makes sense when we have relative urls with parameters and query, for e.g.'g:h','?x' Another way to handle this would be split urlparse into two methods: urlparse.absparse() urlparse.relparse() and let the user decide what he wants to do. I am passing a message to Web-SIG to discuss this further. Irrespective of this, if the patch looks okay for "handling the port issue" for 2.6 with the "Doc/Help message", then we should close this bug and take the discussion further in Web-SIG. (I shall provide the patch for 3.0 as well) Comments Please. Added file: http://bugs.python.org/file10752/issue754016-py26.patch _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue754016> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
