It seems odd that it would be per module and not per scope? On Tue, 22 Jun 2021, 00:55 Soni L., <fakedme...@gmail.com> wrote:
> > > 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 > > > > > > foo.bar > > > > > > would be sugar for > > > > > > __getattr__(foo, "bar") > > > > > > (where __getattr__ defaults to builtins.getattr) instead of being > sugar for > > > > > > <builtins.getattr>(foo, "bar") > > > > 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. > > > > https://www.python.org/dev/peps/pep-0562/ > > > > > > 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? > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/MTOP22VK2ZC3GWCQHU5RDFVIT5AAR4DW/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OQOJ3LZLCYKCYJW2ZTHQ2OQULKDFPWVC/ Code of Conduct: http://python.org/psf/codeofconduct/
