GeezerVison

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.old_request 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?

-Brett