(original) (raw)

On Mon, Dec 1, 2014 at 1:27 AM, Guido van Rossum <guido@python.org> wrote:
\> Nathaniel, did you look at Brett's LazyLoader? It overcomes the subclass
\> issue by using a module loader that makes all modules instances of a
\> (trivial) Module subclass. I'm sure this approach can be backported as far
\> as you need to go.

The problem is that by the time your package's code starts running,
it's too late to install such a loader. Brett's strategy works well
for lazy-loading submodules (e.g., making it so 'import numpy' makes
'numpy.testing' available, but without the speed hit of importing it
immediately), but it doesn't help if you want to actually hook
attribute access on your top-level package (e.g., making 'numpy.foo'
trigger a DeprecationWarning -- we have a lot of stupid exported
constants that we can never get rid of because our rules say that we
have to deprecate things before removing them).

Or maybe you're suggesting that we define a trivial heap-allocated
subclass of PyModule\_Type and use that everywhere, as a
quick-and-dirty way to enable \_\_class\_\_ assignment? (E.g., return it
from PyModule\_New?) I considered this before but hesitated b/c it
could potentially break backwards compatibility -- e.g. if code A
creates a PyModule\_Type object directly without going through
PyModule\_New, and then code B checks whether the resulting object is a
module by doing isinstance(x, type(sys)), this will break. (type(sys)
is a pretty common way to get a handle to ModuleType -- in fact both
types.py and importlib use it.) So in my mind I sorta lumped it in
with my Option 2, "minor compatibility break". OTOH maybe anyone who
creates a module object without going through PyModule\_New deserves
whatever they get.