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

[Brett Cannon]

On Fri, Feb 29, 2008 at 2:27 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>
> On 2008-02-29 01:47, Brett Cannon wrote:
>  > [BCC'ing stdlib-sig and web-sig so that both vote but that I don't
>  > have to clear a bunch of replies in the stdlib-sig mailing list from
>  > people not on both lists =) ]
>  >
>  > 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
>  >
>  > So, if you have an opinion please speak up!
>
>  urllib and urllib2 use rather different approaches to extending.
>  urllib needs to be subclassed, while urllib2 uses handlers that
>  you can plug in to get different functionality.
>
>  I don't see how you could easily move code using one approach
>  to then use the other in Py3k.
>
>  As for usage, urllib is by far more used than urllib2 (just check
>  Google Code Search to get an idea).
>
>  Then again, most use of urllib is probably just calling
>  urllib.urlopen() and not doing any of the fancy stuff like
>  adding extra error handling. If urllib2's urlopen() works in
>  the same way as urllib.urlopen(), the move would be easy
>  for this use case.
>

The main difference is urllib.urlopen() has a proxies argument and
urllib2.urlopen() has a timeout option. Otherwise the interface on the
returned object, best I can tell, is the same.

>  For the second common use of subclassing urllib.URLopener
>  or urllib.FancyURLopener, removing urllib altogether would
>  mean having to rewrite the code to use the different
>  handler approach in urllib2.
>

Not necessarily. As has been stated, urllib can be released as an
external library for people who want to use that instead of shift over
to urllib2. That way the stdlib gets cleaner without forcing people to
have to retool their code in order to keep using old libraries.

>  However, this is not necessary if we copy over the two
>  classes to url.request.
>
>  So, I'd be +1 on the second approach, provided that those
>  two classes make the transition into url.request as
>  well. Otherwise, I'm +1 on the first approach and -1
>  on the second.
>

Just to make sure I got this straight, as long as the two classes
without the urllib._urlopener support from urlopen() are moved forward
you are happy with this? What about making urllib an external library
people can download and install using distutils?

-Brett