[Python-Dev] Trickery with moving urllib (original) (raw)

Jeremy Hylton jeremy at alum.mit.edu
Sun May 11 18:02:38 CEST 2008

On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <brett at python.org> wrote:

There is going to be an issue with the current proposal for keeping around urllib. Since the package is to be named the same thing as the module, to handle the new name that means urllib.init will need to gain the Py3K warning for the new name. But that doesn't quite work as the package's module will be imported automatically any time the module within the package is used.

I see three solutions for dealing with this. 1. Have stubs for the entire urllib API in urllib.init that raise a DeprecationWarning either specifying the new name or saying the function/class is deprecated. 2. Rename urllib to urllib.fetch or urllib.oldrequest to get people to move over to urllib.request (aka urllib2) at some point. 3. Ditch urllib completely and have people move to urllib.request directly from 2.6 going into 3.0. I was a fan of 3 in the stdlib SIG, but MAL argued well for 2 since so much code uses urllib (although I have always wondered how many really use urllib and how many could easily just move over to urllib2). The current solution of keeping around urllib's classes was a compromise, but I had not thought out the transition yet (and Jeremy Hylton will be running into this as he has volunteered to handle this). What do people think we should do?

I am migrating all the stdlib code to use urllib2 APIs when possible. It seems straightforward enough to keep the old urllib classes in urllib.request, but change the standard API functions (urlopen, urlretrieve) to use the urllib2 implementation.

We could probably have a big collection of deprecation warnings in the urllib/init without much trouble. It doesn't have any code at this point.

Jeremy

-Brett

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu

More information about the Python-Dev mailing list