Python dot-equals (syntax proposal)
in [Python]
|
Prev: Python daemonisation with python-daemon
Next: External Hashing [was Re: matching strings in a large set of strings]
From: Lie Ryan on 2 May 2010 02:28 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.
From: Lie Ryan on 2 May 2010 03:09 On 05/02/10 10:58, Steven D'Aprano wrote: > On Sun, 02 May 2010 05:08:53 +1000, Lie Ryan wrote: > >> > On 05/01/10 11:16, Steven D'Aprano wrote: >>> >> On Fri, 30 Apr 2010 12:34:34 -0400, D'Arcy J.M. Cain wrote: >>> >> >>> >> In practice though, I think that's a difference that makes no >>> >> difference. It walks like an operator, it swims like an operator, and >>> >> it quacks like an operator. >>> >> >>> >> >> > Nope it's not. A full-time operator in python have a reflected version >> > (e.g. __radd__), which dot does not have. > What are the reflected versions of __eq__ and __ne__ (binary == and != > operators)? Python do not have them now, but it does make sense if python have them[1]. OTOH, given current python's language semantic, __rgetattr__ doesn't make any sense; adding __rgetattr__ would require a quite fundamental change to the language's semantic, primarily how attribute resolution works. [1] though they'd probably be dismissed as bad idea since equality and inequality are supposed to be a symmetric relation; reflected (in)equality makes it way too easy to break that premise > And __neg__, __pos__ and __inv__ (for the unary - + and ~ operators)? > > And the three-argument form of __pow__ for power(1, 2, x)? I know you're a famed nitpicker, but don't be silly, reflected operator, by definition, only makes sense for binary operator.
From: Terry Reedy on 2 May 2010 04:04 On 5/2/2010 1:05 AM, Alf P. Steinbach wrote: > On 02.05.2010 06:06, * Aahz: >> and sometimes >> they rebind the original target to the same object. > > At the Python level that seems to be an undetectable null-operation. If you try t=(1,2,3); t[1]+=3, if very much matters that a rebind occurs. > Granted one could see something going on in a machine code or byte code > debugger. But making that distinction (doing nothing versus > self-assignment) at the Python level seems, to me, to be meaningless. Please do not confuse things. Augmented *assignment* must be understood as assignment. Failure to do so leads (and has lead) newbies into confusion, and puzzled posts on this list. Terry Jan Reedy
From: Steven D'Aprano on 2 May 2010 05:21 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
From: Steven D'Aprano on 2 May 2010 05:24
On Sun, 02 May 2010 17:09:36 +1000, Lie Ryan wrote: > On 05/02/10 10:58, Steven D'Aprano wrote: >> On Sun, 02 May 2010 05:08:53 +1000, Lie Ryan wrote: >> >>> > On 05/01/10 11:16, Steven D'Aprano wrote: >>>> >> On Fri, 30 Apr 2010 12:34:34 -0400, D'Arcy J.M. Cain wrote: >>>> >> >>>> >> In practice though, I think that's a difference that makes no >>>> >> difference. It walks like an operator, it swims like an operator, >>>> >> and it quacks like an operator. >>>> >> >>>> >> >>> > Nope it's not. A full-time operator in python have a reflected >>> > version (e.g. __radd__), which dot does not have. >> What are the reflected versions of __eq__ and __ne__ (binary == and != >> operators)? > > Python do not have them now, but it does make sense if python have > them[1]. OTOH, given current python's language semantic, __rgetattr__ > doesn't make any sense; adding __rgetattr__ would require a quite > fundamental change to the language's semantic, primarily how attribute > resolution works. > > [1] though they'd probably be dismissed as bad idea since equality and > inequality are supposed to be a symmetric relation; reflected > (in)equality makes it way too easy to break that premise > >> And __neg__, __pos__ and __inv__ (for the unary - + and ~ operators)? >> >> And the three-argument form of __pow__ for power(1, 2, x)? > > I know you're a famed nitpicker, but don't be silly, reflected operator, > by definition, only makes sense for binary operator. Binary operators aren't the only kind of operator, and you claimed that: "A full-time operator in python have a reflected version". But there are full-time operators that don't have reflected versions, so your claim is just *wrong*. It would still be wrong even if you had limited yourself to binary operators. I have agreed with you that there are useful things people might want to do (e.g. function composition) that you can't do because the "dot operator" isn't a *real* operator with exactly the same semantics as "plus operator", "multiply operator" and friends. I think we're in violent agreement, and merely disagreeing over semantics. There's no need to continue arguing against a position I haven't actually taken :) -- Steven |