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

[M.-A. Lemburg]

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.

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.

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.

Python just got off the ground for doing web programming,
so making life hard for people using it in that application
space is not a good idea.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 29 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611