[stdlib-sig] Any ideas on how to handle urllib, urllib2, and urlparse?

Steven Bethard steven.bethard at gmail.com
Wed Feb 20 19:12:19 CET 2008


On Feb 20, 2008 9:47 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> Christian Heimes wrote:
> > Facundo Batista wrote:
> >> What to do with the methods that will be lost because of keeping a
> >> slightly different one with the same functionality? We could keep them
> >> with a deprecation warning, or simply let them disappear (+0 for the
> >> former, even considering we're in 3k).
> >
> > Merging urllib and urllib2 into a completely new module with a (although
> > slightly) different API is a good thing. But it also increases the
> > burden and workload for Python users. We should keep the original
> > modules around if a change can't be handled by a 2to3 fixer. We can
> > always deprecate a module for 3.1.
> >
> > For urllib/urllib2 I propose:
> >
> > * merge the functionality into a new, improved module
> > * keep the original ones around for 3.0 and schedule them for removal in
> > 3.1.
>
> I'm not sure that would work: urllib is one of the most used modules
> in Python when it comes to doing even only slightly web-related
> work.
>
> I've never used urllib2 and am not sure what the reason was for
> adding it. It doesn't appear to offer more or better things than
> urllib... to late to argue, I guess ;-)

I'm pretty sure the intent of urllib2 is to give better error messages
than urllib.  I only use urllib2 in my own code for that reason.  (I
don't remember what confusing error I got from urllib that made me
switch, but I remember that there was one.)

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy


More information about the stdlib-sig mailing list