On Fri, Feb 29, 2008 at 2:27 AM, M.-A. Lemburg <[EMAIL PROTECTED]> 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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
