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 _______________________________________________ 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
