PEP 713: Callable Modules

[oscarbenjamin]

@njs

This isn’t necessarily a blocker – we still added the special __getattr__ and __setattr__ support despite those already being possible through __class__ assignment.

Is there __setattr__ support?

There is a parallel thread proposing to add that:

Extend PEP 562 with __setattr__ for modules?

Since CPython 3.5 it’s possible to customize setting module attributes by setting __class__ attribute. Unfortunately, this coming with a measurable speed regression for attribute access: $ cat b.py x = 1 $ python -m timeit -r11 -s 'import b' 'b.x' 5000000 loops, best of 11: 48.8 nsec per loop $ cat c.py import sys, types x = 1 class _Foo(types.ModuleType): pass sys.modules[__name__].__class__ = _Foo $ python -m timeit -r11 -s 'import c' 'c.x' 2000000 loops, best of 11: 131 nsec per loop For r…

As mentioned there one downside of setting __class__ is that it slows down all attribute access and reading attributes from a module is very common (np.sin(...) etc).

@njs

it would also be nice if we came out of the discussion with more general principles about which module dunders are worth special-casing and which aren’t.

In ordinary Python code modules are namespaces and their interface is only expected to provide attributes. The __getattr__ proposal (PEP 562) has a clear motivation around accessing deprecated attributes. PEP 562 also added __dir__ which is for listing attributes. The __setattr__ proposal in the other thread is motivated by wanting to disallow (or warn about) setting attributes in cases where it could be a likely user error to do so. I don’t see why any special support should be added to encourage defining modules that have unusual features besides attribute access: most other operations should generally be expected to give TypeError.