The purpose is to encapsulate all URL handling functions in one module. At the moment there are three modules that dissect URLs for various bits of information. These are urlparse - to split url into components, urllib - to decode splitted data and cgi - to parse query component. To outline the API of the proposed module I'll start with urlparse : http://docs.python.org/lib/module-urlparse.html 1. There are two identical functions - urlparse and urlsplit that make the same parsing operation, but vary in format of return arguments. They could be replaced with one - let's call it urlsplitex - that returns result in a class with attributes - not a subclass of list, but rather dictionary subclass, because positional arguments are evil and you always have to look into reference to find out the correct order if you read or debug the code. 2. Returned class should not be immutable. It must be possible to modify the results to unset extra parts (like fragments) or edit required parts as needed and get the target URL via urlunsplitex or embedded method of the same class. Thus arguments "default_scheme" and "allow_fragments" will be useless as well as function urldefrag. 3. urlparsex, a replacement for "parsing" function of the new library should be high-level functions to dissect url information into tree-like structure with atomic leafs. This includes decoding url entities and splitting parameters into child structures. The proposed structure of url class attributes is: scheme string netloc class username string password string server string port integer path list with objects of class part string param list with objects of class name string value string query list with objects of class name string value string fragment string 4. urlunparsex will be provided to reassemble class back into URL. This will deprecate series of functions from urllib like quote, unquote, urlencode and also functions parse_qs and parse_qsl from cgi module. References: http://mail.python.org/pipermail/patches/2005-February/016972.htmlhttp://bugs.python.org/issue1722348http://bugs.python.org/issue1462525
You missed urllib2 I think. :-) I agree it's a mess. I'm sure it all started out with backwards compatibility in mind. I find myself often importing cgi only to use the tiny function escape() that is defined there... I wonder if web-sig wouldn't be a good place to get some kindred spirits together to redesign these APIs for Py3k?
I have started this work at http://svn.python.org/projects/sandbox/trunk/urilib/ as a part of G-SoC, yes taking it to web-sig would be appropriate and I shall do so. techtonik, you might want to review it urilib and we can discuss it further. Thanks,
Yes, the modules should probably all get merged somehow. But discussing it in the web-sig is fine with me and I am happy to look at what the web-sig ends up recommending.
Brett, in consideration of PEP 3108... shouldn't we close this issue? The urilib module in the sandbox wasn't updated in the last seven months. Or we just keep this open as a reminder? (of what?) Thanks!
