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