On 2 Apr, 20:17, "Kay Schluehr" <[EMAIL PROTECTED]> wrote: > > Note that the conflict of putting modules on top level or better > within separate packages is not an either-or decision from a > programmers point of view who just wants to access those modules. A > top level module like lib or std can be pretty virtual since you can > create modules at runtime whenever you try to import them.
Or, if the subpackages/submodules are small enough, just import them and make their contents available at higher levels in the hierarchy. > I used this strategy for a project where editing objects in separate files > leaded > to a better overview compared to one large file containing all > definitions. However I created one module at runtime that served as a > common access point for all these particular definitions that were > tedious to import separately and would have required file system > lookups quite often. This might even allow multiple classifications > but I haven't experimented with them yet. Yes, I tend to make aliases available quite a bit. It seems to me that introducing a hierarchy into the standard library has a fairly limited cost: you need to occupy some more top-level names, some unfortunately being potentially common, but any growth in the library isn't as likely to introduce more naming conflicts - something that anyone with their own calendar.py, new.py or xml.py programs might find desirable. ;-) One problem I've become more aware of, however, is the role of C-based modules in the library. I think there was an unresolved issue about such modules living at non-root locations in the library hierarchy, but aside from that, the work required to clean up any abstractions eventually requires people to roll up their sleeves and look at non- Python code. Paul -- http://mail.python.org/mailman/listinfo/python-list
