[Python-ideas] Module __getattr__ [Was: breaking out of module execution]

[Steven D'Aprano]

Gregory P. Smith wrote:

> Making modules "simply" be a class that could be subclasses rather than
> their own thing _would_ be nice for one particular project I've worked on
> where the project including APIs and basic implementations were open source
> but which allowed for site specific code to override many/most of those
> base implementations as a way of customizing it for your own specific (non
> open source) environment.  


This makes no sense to me. What does the *licence* of a project have to do 
with the library API? I mean, yes, you could do such a thing, but surely you 
shouldn't. That would be like saying that the accelerator pedal should be on 
the right in cars you buy outright, but on the left for cars you get on 
hire-purchase.

Nevertheless, I think your focus here is on the wrong thing. It seems to me 
that you are jumping to an implementation, namely that modules should stop 
being instances of a type and become classes, without having a clear idea of 
your functional requirements.

The functional requirements *might* be:

"There ought to be an easy way to customize the behaviour of attribute access 
in modules."

Or perhaps:

"There ought to be an easy way for one module to shadow another module with 
the same name, but still inherit behaviour from the shadowed module."

neither of which *require* modules to become classes.

Or perhaps it is something else... it is unclear to me exactly what problems 
you and Jim wish to solve, or whether they're the same kind of problem, which 
is why I say the functional requirements are unclear.

Changing modules from an instance of ModuleType to "a class that could be a 
subclass" is surely going to break code. Somewhere, someone is relying on the 
fact that modules are not types and you're going to break their application.


> Any APIs that were unfortunately defined as a
> module with a bunch of functions in it was a real pain to make site
> specific overrides for.  

It shouldn't be. Just ensure the site-specific override module comes first in 
the path, and "import module" will pick up the override module instead of the 
standard one. This is a simple exercise in shadowing modules.

Of course, this implies that the override module has to override *everything*. 
There's currently no simple way for the shadowing module to inherit 
functionality from the shadowed module. You can probably hack something 
together, but it would be a PITA.



-- 
Steven