On 2021-06-23 03:02, Steven D'Aprano wrote:
Attribute lookups are just another form of name lookup. Name lookups
depend on the current execution scope, not the caller's scope. With
extension methods, so do attribute lookups.
But that's the thing, they aren't. You gave a bunch of examples of
lexical scope semantics with imports and function locals vs globals.
But attribute lookups do not work that way. Attribute lookups are
defined to work via a FUNCTION CALL to the __getattribute__ (and thence
often the __getattr__) of the OBJECT whose attribute is being looked up.
They do not in any way depend on the name via which that object is
accessed.
Now of course you can say that you want to make a new rule that throws
the old rules out the window. We can do that for anything. We can
define a new rule that says now when you do attribute lookups it will
call a global function called attribute_lookups_on_tuesdays if it's a
Tuesday in your timezone. But what I'm saying is that the way attribute
lookups currently work is not the same as the way bare-name lookups
work, because attribute lookups are localized to the object (not the
name!) and bare-name lookups are not. I consider this difference
fundamental to Python. It's why locals() isn't really how local name
lookups work (which came up elsewhere in this thread). It's why you
can't magically hook into "x = my_obj" and create some magical behavior
that depends on my_obj. Attribute lookups are under the control of the
object; they come after the scope-based name resolution is all over with
and they don't use the scope-based rules.
As for other languages, you keep referencing them as if the fact that
something known as "extension methods" exists in those other languages
makes it self-evident that it would be useful in Python. Python isn't
those other languages. I'm not familiar with all of the other languages
you mentioned, but I'll bet that at least some of them do not have the
same name/attribute lookup rules and dunder-governed
object-customization setup as Python. So that's the difference. The
fact that extension methods happen to exist and be useful in those
languages is really neither here nor there. The attribute lookup
procedure you are proposing is deeply inconsistent with the way Python
currently does attribute lookup and currently does other things (like
operator overloading), and doesn't fit into Python's overall mechanism
of object-based hooks. A spatula attachment may be useful on a kitchen
mixer; that doesn't mean it's a good idea to add one to your car's
dashboard.
Apart from that, I will say that I also don't generally assume that
because other languages have a feature it's good or worth considering.
Some languages are better designed than others. I think Python is a
very well designed language. Certainly we can learn from other
languages, but even apart from the issues of "fit" that I describe
above, the mere fact that some feature is available or even considered
useful in other languages doesn't by itself even convince me it's a good
idea at all. It could just be a mistake. We need to specifically show
that this will make writing and/or reading code easier and better in
Python, and I think this proposal would do the opposite, making code
harder to read.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
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/FTHXJDHPE5UFVQE5WSBJN6ZURZKWUFFY/
Code of Conduct: http://python.org/psf/codeofconduct/
