On 2021-06-21 8:42 p.m., Steven D'Aprano wrote:
On Mon, Jun 21, 2021 at 02:54:52PM -0300, Soni L. wrote:
Quite the opposite. You ask the local module (the one that the code was compiled in), and the module decides whether/when to ask the object itself.
In other words, every
would be sugar for
(where __getattr__ defaults to builtins.getattr) instead of being sugar for
All you've done here is push the problem further along -- how does `__getattr__` (`__getattribute__`?) decide what to do?
Why is this extension-aware version per module, instead of a builtin?
Does that mean the caller has to write it in every module they want to make use of extensions?
Why do we need a second attribute lookup mechanism instead of having the existing mechanism do the work?
And most problematic, if we have an extension method on a type, the builtin getattr ought to pick it up.
By the way, per-module `__getattr__` already has a meaning, so this name won't fly.
No, you got it wrong. Extension methods don't go *on* the type being extended. Indeed, that's how they differ from monkeypatching.
The whole point of extension methods *is* to be per-module. You could shove it in the existing attribute lookup mechanism (aka the builtins.getattr) but that involves runtime reflection, whereas making a new, per-module attribute lookup mechanism specifically designed to support a per-module feature would be a lot better.
Extension methods *do not go on the type*.
And sure, let's call it __opcode_load_attr_impl__ instead. Sounds good?