[Python-Dev] Great Renaming? What is the goal?
Mon, 27 Mar 2000 00:08:57 -0800 (PST)
Your question as to the purpose of module reorganization is
well worth asking, and perhaps we should stand back for a
while and try to really answer it well first.
I think that my answers for your question would be:
1. To alleviate potential namespace collision.
2. To permit talking about packages as a unit.
I hereby solicit other reasons from the rest of the group...
Reason #1 is not a serious problem yet, but i think i've
seen a few cases where it might start to be an issue.
Reason #2 has to do with things like assigning people
responsibility for taking care of a particular package,
or making commitments about which packages will be
available with which distributions or platforms. Hence,
for example, the idea of the "unix" package.
Neither of these reasons necessitate a deep and holy
hierarchy, so we certainly want to keep it shallow and
simple if we're going to do this at all.
> If the result of this renaming initiative will be that I can't use
> import sys, os, time, re, struct, cPickle, parser
> import Tkinter; Tk=Tkinter; del Tkinter
> anymore in Python 1.x and instead I have to change this into (for example):
> form posix import time
> from text import re
> from bin import struct
> from Python import parser
> from ui import Tkinter; ...
import sys, os, time.time, text.re, bin.struct, data.pickle, python.parser
also work? ...i hope?
> The library documentation provides a existing logical subdivision into
> chapters, which group the library into several kinds of services.
> IMO this subdivision could be discussed and possibly revised.
> But at the moment I got the impression, that it was simply ignored.
> Why? What's so bad with it?
I did look at the documentation for some guidance in arranging
the modules, though admittedly it didn't direct me much.
"In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand."
-- Gerald Holton