I agree with this. Of all the dunders that might be useful for modules, __call__ seems like an odd one to start with. I’d actually be more receptive to a generic argument for supporting all normal customizable dunders than for just supporting __call__ on its own.
When discussing this or any other PEP, be sure to read the PEP first, and discus its technical merits. Don’t start discussing other ideas or expanding the scope of the PEP, as then the discussion goes off topic discussing the merits of those ideas instead of the PEP.
PEP 713 is very small. It acknowledges that a module can already be made callable. It exists because it wants a standard way for type checkers to recognize that. It does not suggest adding it to any particular modules. It does not suggest adding other special methods to modules.
The PEP author has indicated to me that this discussion is no longer about the PEP itself, and is unhelpful towards the goal of improving the PEP or moving it towards the approval process. At this point, they’ll submit it to the SC if and when they feel ready to do so.
6 Likes
“”" Hi, thanks for writing up the nice PEP spawning the lively discussion around callable modules.
The steering council has discussed this PEP and decided to Reject it. (as I mentioned we were leaning towards in PEP 713: Callable Modules - #66 by gpshead)
We didn’t feel that there was a compelling reason to have it even though it clearly could be done from a consistency point of view. I wouldn’t be surprised if this idea comes up again in the future. If so, this is a useful prior discussion to refer to for when it does.
– The Python Steering Council
“”" - PEP 713 -- Callable Modules · Issue #191 · python/steering-council · GitHub
Tangentially related in the “modules gaining more dunder function abilities” theme… a new proposal regarding __setattr__ and __delattr__ is now also being discussed.
2 Likes