On Fri, 24 Mar 2000, Guido van Rossum wrote: > [Greg] > > And why *can't* we start on repackaging old module? I think the only > > reason that somebody came up with to NOT do it was "well, if we don't > > repackage the whole thing, then we should repackage nothing." Which, IMO, > > is totally bogus. We'll never get anywhere operating under that principle. > > The reason is backwards compatibility. Assume we create a package > "web" and move all web related modules into it: httplib, urllib, > htmllib, etc. Now for backwards compatibility, we add the web > directory to sys.path, so one can write either "import web.urllib" or > "import urllib". But that loads the same code twice! And in this > (carefully chosen :-) example, urllib actually has some state which > shouldn't be replicated. We don't add it to the path. Instead, we create new modules that look like: ---- httplib.py ---- from web.httplib import * ---- The only backwards-compat issue with this approach is that people who poke values into the module will have problems. I don't believe that any of the modules were designed for that, anyhow, so it would seem an acceptable to (effectively) disallow that behavior. > Plus, it's too much work -- I'd rather focus on getting 1.6 out of the > door, and there's a lot of other stuff I need to do besides moving > modules around. Stuff that *you* need to do, sure. But there *are* a lot of us who can help here, and some who desire to spend their time moving modules. Cheers, -g -- Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4