Peter Funk quoted:
>Fredrik Lundh:
>> I'm not so sure that Python really needs a simple reorganization
>> of the existing set of standard library modules. just moving the
>> modules around won't solve the real problems with the 1.5.2 std
>> library...
>Right. I propose to leave the namespace flat.
I third that comment. Arguments against reorganizing for 1.6:
1) I doubt that we have time to do a good job of it for 1.6.
(1.7, maybe.)
2) Right now there's no way for third-party extensions to add
themselves to a package in the standard library. Once Python finds
foo/__init__.py, it won't look for site-packages/foo/__init__.py, so
if you grab, say, "crypto" as a package name in the standard library,
it's forever lost to third-party extensions.
3) Rearranging the modules is a good chance to break backward
compatibility in other ways. If you want to rewrite, say, httplib
in a non-compatible way to support HTTP/1.1, then the move from
httplib.py to net.http.py is a great chance to do that, and leave
httplib.py as-is for old programs. If you just copy httplib.py,
rewriting net.http.py is now harder, since you have to either
maintain compatibility or break things *again* in the next version
of Python.
4) We wanted to get 1.6 out fairly quickly, and therefore limited
the number of features that would get in. (Vide the "Python 1.6
timing" thread last ... November, was it?) Packagizing is feature
creep that'll slow things down
Maybe we should start a separate list to discuss a package hierarchy
for 1.7. But for 1.6, forget it.
--
A.M. Kuchling http://starship.python.net/crew/amk/
Posting "Please send e-mail, since I don't read this group": Poster is
rendered illiterate by a simple trepanation.
-- Kibo, in the Happynet Manifesto
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