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 -- http://mail.python.org/mailman/listinfo/python-list
