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

[Brett Cannon]

On Feb 20, 2008 8: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.
>

That is I figured no one would be willing to see urllib or urllib2 go.

> 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 actually use urllib2 over urllib because I find it easier to
overload with custom HTTP headers.

> In any case, deprecating a module after the jump to 3.0 is more
> problematic than during the major version number change.
>

I agree, but it is certainly doable.

> How about using the following mapping:
>
> urllib  -> url.fetch
> urllib2 -> url.request
>

I can live with that. What do other people think?

-Brett