[Web-SIG] Choosing one of two options for url* in the stdlib reorg

Brett Cannon brett at python.org
Fri Feb 29 02:17:24 CET 2008


On Thu, Feb 28, 2008 at 5:07 PM, Robert Brewer <fumanchu at aminus.org> wrote:
> Brett Cannon wrote:
>  > With PyCon approaching and having other stuff on my plate to deal with
>  > I want to try to reach a consensus on the whole
>  > urllib/urllib2/urlparse situation for the stdlib reorg in Python 3.0
>  > and get it settled.
>  >
>  > So, two options for people to show support for.  One is to keep
>  > everything and get cute with the naming::
>  >
>  >   urlparse -> url.parse
>  >   urllib -> url.fetch
>  >   urllib2 -> url.request
>  >
>  > The second option is to ditch urllib, move the handy quoting tools
>  > into either their own module or into what is currently urllib2::
>  >
>  >   urlparse -> url.parse
>  >   urllib -> GONE
>  >   urllib's utility functions -> url.quote
>  >   urllib2 -> url.request
>
>  +0.5 for this second option. But what will happen to all the other names
>  urllib2 currently imports from urllib that aren't "quotey"?
>
>     from urllib import (unwrap, unquote, splittype, splithost,
>          addinfourl, splitport, splitgophertype, splitquery,
>          splitattr, ftpwrapper, noheaders, splituser, splitpasswd,
>  splitvalue)
>

It can be moved to where ever it needs to go. Anything that is not
publicly exposed can just stay hidden. Otherwise it just shifts to one
of the modules in the package.

>  I wouldn't mind if "urllib's utility functions" just moved into
>  url.parse. Then we'd have one module for parsing (and unparsing) URL's
>  and one for actually using them.
>

Having only url.parse and url.request is fine by me. The real question
is whether urllib needs to stay 3.0 or not. Once that is decided
organizing the merge can begin.

-Brett


More information about the Web-SIG mailing list