Standard Library Structure (was Re: Shed Skin Python-to-C++ Compiler 0.0.21, Help needed)

[Paul Boddie]

On 2 Apr, 20:17, "Kay Schluehr" <kay.schlu... at gmx.net> 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