Python dot-equals (syntax proposal)
Steven D'Aprano
steve at REMOVE-THIS-cybersource.com.au
Sun May 2 05:21:16 EDT 2010
On Sun, 02 May 2010 16:28:28 +1000, Lie Ryan wrote:
> On 05/02/10 10:58, Steven D'Aprano wrote:
>>> > And Python's object system
>>> > makes it that the argument to __getattr__ is always a string even
>>> > though there might be a valid variable that corresponds to it:
>> That is nothing to do with the object system, it is related to the
>> semantics of Python syntax. a.b doesn't mean "apply the binary dot
>> operator to arguments a and b". It is syntactic sugar for "look for an
>> attribute named 'b' on object a". As such, the operands that
>> __getattr__ receives are the object a and the *name* b (implemented as
>> a string).
>
> You just described *exactly* the reason why dot is not, and cannot be an
> operator.
This would be relevant if I said it was an operator. I did not. I said it
was a de facto operator that behaves similarly enough to operators as to
make it reasonable to talk about "dot operator". I still stand by that.
That doesn't imply that Python's implementation of a.b has to be
identical in every last detail to Python's implementation of a+b, because
it clearly isn't. But there are sufficient similarities to justify saying
that it duck-types as an operator. This isn't meant to be a vigorous
statement of fact in the same manner than "CPython implements lists as
arrays of pointers" is a statement of fact. It's meant to be a hand-wavy
"dot act kinda-sorta like an operator" manner.
I'm sorry if I failed to make that clear enough. I thought that
explicitly stating that it wasn't a real operator would be sufficient.
--
Steven
More information about the Python-list
mailing list