On Tue, Jun 22, 2021 at 01:49:56AM +1000, Chris Angelico wrote: > So what you're saying is that, in effect, every attribute lookup has > to first ask the object itself, and then ask the module? Which module? > The one that the code was compiled in? The one that is currently > running? Both?
Mu. https://en.wikipedia.org/wiki/Mu_(negative)#%22Unasking%22_the_question We don't have an implementation yet, so it is too early to worry about precisely where you look up the extension methods, except that it is opt-in (so by default, there's no additional cost involved) and there must be *some* sort of registry *somewhere* that handles the mapping of extension methods to classes. We certainly don't want this to slow down *every method call*, but if it only slowed down method lookups a little bit when you actually used the feature, that might be acceptable. We already make use of lots of features which are slow as continental drift compared to C, because they add power to the language and are *fast enough*. E.g. name lookups are resolved at runtime, not compile-time; dynamic attribute lookups using gettattribute and getattr dunders; virtual subclasses; generic functions (functools.singledispatch); descriptors. > And how is this better than just using a plain ordinary function? Not > everything has to be a method. You get method syntax, obj.method, which is nice but not essential. When a method is called from an instance, you know that the first parameter `self` has got to be the correct type, no type-checking is required. That's good. And the same would apply to extension methods. You get bound methods as first class values, which is useful. You get inheritance, which is powerful. And you get encapsulation, which is important. I think this is a Blub moment. We don't think it's useful because we have functions, and we're not Java, so "not everything needs to be a method". Sure, but methods are useful, and they do bring benefits that top-level functions don't have. (And vice versa of course.) We have staticmethod that allows us to write a "function" (-ish) but get the benefits of inheritance, encapsulation, and method syntax. This would be similar. We acknowledge that there are benefits to monkey-patching. But we can't monkey-patch builtins and we are (rightly) suspicious of those who use monkey-patching in production. And this is good. But this would give us the benefits of monkey-patching without the disadvantages. *If* we can agree on semantics and come up with a reasonable efficient implementation that doesn't slow down every method call. -- Steve _______________________________________________ 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/QCEC764ILFOUDWO5HXVKTTJSA6XIT6KI/ Code of Conduct: http://python.org/psf/codeofconduct/
