Trickery with moving urllib
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
Brett> There is going to be an issue with the current proposal for Brett> keeping around urllib. Since the package is to be named the same Brett> thing as the module.... Is this the only module morphing into a package of the same name? Skip
On Sat, May 10, 2008 at 11:43 PM, <skip@pobox.com> wrote:
Brett> There is going to be an issue with the current proposal for Brett> keeping around urllib. Since the package is to be named the same Brett> thing as the module....
Is this the only module morphing into a package of the same name?
No, it is not. The dbm package will have the same issue. -- Alexandre
-Brett [from his iPod touch] On 10-May-08, at 23:46, "Alexandre Vassalotti" <alexandre@peadrop.com> wrote:
On Sat, May 10, 2008 at 11:43 PM, <skip@pobox.com> wrote:
Brett> There is going to be an issue with the current proposal for Brett> keeping around urllib. Since the package is to be named the same Brett> thing as the module....
Is this the only module morphing into a package of the same name?
No, it is not. The dbm package will have the same issue.
Ah nuts, forgot about that one. -Brett
-- Alexandre
On 10-May-08, at 20:43, skip@pobox.com wrote:
Brett> There is going to be an issue with the current proposal for Brett> keeping around urllib. Since the package is to be named the same Brett> thing as the module....
Is this the only module morphing into a package of the same name?
Yes. -Brett
Skip
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <brett@python.org> wrote:
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.
I am probably missing something, because I don't see how this solution would solve the problem. The warning in urllib.__init__ will still be issued when people will import urllib.fetch (or urllib.fetch). -- Alexandre
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <brett@python.org> wrote:
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.
On May 11, 2008, at 2:58 AM, Alexandre Vassalotti wrote:
I am probably missing something, because I don't see how this solution would solve the problem. The warning in urllib.__init__ will still be issued when people will import urllib.fetch (or urllib.fetch).
Were the warnings issued on import, yes, but I think Brett's suggestion was really about issuing warnings when the stub functions were called. For classes, I guess this could be handled using the __init__ methods, but I'm not sure I like that, or that it will be easy to get exactly the right behavior in all cases. -Fred -- Fred Drake <fdrake at acm.org>
-Brett [from his iPod touch] On 11-May-08, at 0:04, Fred Drake <fdrake@acm.org> wrote:
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <brett@python.org> wrote:
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.
On May 11, 2008, at 2:58 AM, Alexandre Vassalotti wrote:
I am probably missing something, because I don't see how this solution would solve the problem. The warning in urllib.__init__ will still be issued when people will import urllib.fetch (or urllib.fetch).
Were the warnings issued on import, yes, but I think Brett's suggestion was really about issuing warnings when the stub functions were called. For classes, I guess this could be handled using the __init__ methods, but I'm not sure I like that, or that it will be easy to get exactly the right behavior in all cases.
Another option is to not worry about warnings in this specific case and fully rely on 2to3. The issue of urllib and splitting its API across 2 files stands, though. That could be solved with a urllib._old module for now that eventually gets a deprecation warning.
-Fred
-- Fred Drake <fdrake at acm.org>
-Brett [from his iPod touch] On 10-May-08, at 23:58, "Alexandre Vassalotti" <alexandre@peadrop.com> wrote:
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <brett@python.org> wrote:
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.
I am probably missing something, because I don't see how this solution would solve the problem. The warning in urllib.__init__ will still be issued when people will import urllib.fetch (or urllib.fetch).
No, you are probably right. My brain is mush at the moment. -brett
-- Alexandre
Brett Cannon schrieb:
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.
In this context, what's become of PEP 364? Is it still alive? Does it cover this case? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sun, May 11, 2008 at 8:31 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Brett Cannon schrieb:
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.
In this context, what's become of PEP 364? Is it still alive? Does it cover this case?
PEP 364 was pre-2to3 (Barry and I came up with that solution at the same PyCon 2to3 was conceived). A 2to3 fixer that handles the renames does the same thing; so no, it doesn't solve the issue directly. -Brett
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <brett@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.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?
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu
participants (7)
-
Alexandre Vassalotti -
Brett C. -
Brett Cannon -
Fred Drake -
Georg Brandl -
Jeremy Hylton -
skip＠pobox.com