GeezerVisonThe World Wide Web, restored to 800 pixels of glory. |
| Home|About|Gaming cabinet|Archives|How it works|Starter sites |
GeezerVison is showing mail.python.org — [Python-Dev] Trickery with moving urllib [Python-Dev] Trickery with moving urllibBrett C. bcannon at gmail.comSun May 11 19:50:01 CEST 2008
-Brett [from his iPod touch] On 11-May-08, at 0:04, Fred Drake <fdrake at acm.org> wrote: > On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <brett at 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> > > > >
More information about the Python-Dev mailing list |
| You are visitor 01402520 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |