On 2021-06-21 8:57 p.m., Thomas Grainger wrote: > It seems odd that it would be per module and not per scope?
It's unusual to import things at the scope level. Usually things get imported at the module level, so, using module language doesn't seem that bad. But yes, it's per scope, but in practice it's per module because nobody would actually use this per scope even tho they could. :p > > On Tue, 22 Jun 2021, 00:55 Soni L., <fakedme...@gmail.com > <mailto:fakedme%2...@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/ > <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 > <mailto:python-ideas@python.org> > To unsubscribe send an email to python-ideas-le...@python.org > <mailto:python-ideas-le...@python.org> > https://mail.python.org/mailman3/lists/python-ideas.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/ > > <https://mail.python.org/archives/list/python-ideas@python.org/message/MTOP22VK2ZC3GWCQHU5RDFVIT5AAR4DW/> > Code of Conduct: http://python.org/psf/codeofconduct/ > <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/MBHRH4FTGN7NCCHEHU3HVE4UPDDWHHHY/ Code of Conduct: http://python.org/psf/codeofconduct/
