Re: Python dot-equals (syntax proposal)
On Mon, 03 May 2010 06:37:49 +0200, Alf P. Steinbach wrote: * Terry Reedy: * Alf P. Steinbach: * 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. Testing: test lang=py3 t = ([], [], []) t ([], [], []) t[0] += [blah] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment t (['blah'], [], []) _ /test Yep, it matters. Is this change-but-raise-exception a bug? I seem to have a knack for running into bugs. :-) No, I don't believe so -- I believe that it is behaving exactly as advertised. But it is absolutely a gotcha. Consider: class K(object): ... def __init__(self, value=0): ... self.value = value ... def __add__(self, other): ... self.value = self.value + other ... return self ... def __str__(self): ... return %s % self.value ... __repr__ = __str__ ... x = K(42) x + 5 47 t = (None, x) t (None, 47) t[1] + 3 50 t (None, 50) t[1] += 1 Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment t (None, 51) Unintuitive, yes. Possibly a bad design, maybe. Surprising, absolutely. But not a bug, as it's working exactly as promised. += is conceptually two steps: perform an addition, and perform an assignment afterward. That addition is sometimes performed in-place, but regardless of whether it is or not, the assignment is always attempted. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
Alf P. Steinbach wrote: test lang=py3 t = ([], [], []) t ([], [], []) t[0] += [blah] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment t (['blah'], [], []) _ /test Yep, it matters. Is this change-but-raise-exception a bug? No. a[0] += b translates to a.__setitem__(0, a.__getitem__(0).__iadd__(b)) assuming a[0] has an __iadd__() method. It should be obvious that only the the last operation, the outer a.__setitem__(...), will fail here. A possible fix might be a changed order of evaluation: _internal_set = a.__setitem__ _internal_set(0, a.__getitem__(0).__iadd__(b)) I don't know if there are arguments against this other than increased compiler complexity. Or one could argue that a += b should have been implemented as a = a + b or a = a.__add__(b) which is currently used as the fallback when there is no __iadd__() method and which gives a more intuitive behaviour at the cost of a greater overhead. But it's a little late for that discussion, for that language. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On 5/3/2010 12:37 AM, Alf P. Steinbach wrote: * Terry Reedy: * Alf P. Steinbach: * 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. Testing: test lang=py3 t = ([], [], []) t ([], [], []) t[0] += [blah] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment t (['blah'], [], []) _ /test Yep, it matters. So one should instead write t[0].extend('blah') to the same effect, but without the exception raising assignment attempt, when that is what one really means ;-). Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
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
Re: Python dot-equals (syntax proposal)
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Sun, 02 May 2010 04:04:11 -0400, Terry Reedy wrote: 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. I think that if you think *only* about Python's standard namespaces, self- assignment is more or less a no-op. I can't think of any way that x = x could do anything other than use CPU cycles, *if* you limit yourself to the standard global or function local namespaces. But if you think about custom namespace types, and item assignment (e.g. the example you gave with a tuple), the situation becomes different. Here's a nice example, using Python 3.1: class B(A): # class A defined elsewhere -- see below. ... x = 1 ... x = x ... Traceback (most recent call last): File stdin, line 1, in module File stdin, line 3, in B File stdin, line 4, in __setitem__ TypeError: can't rebind constants Thus proving that self-assignment is not necessarily a no-op. How did I make that work? It takes a custom dict and a bit of metaclass magic: class ConstantNamespace(dict): def __setitem__(self, key, value): if key in self: raise TypeError(can't rebind constants) super(ConstantNamespace, self).__setitem__(key, value) class WriteOnceClass(type): @classmethod def __prepare__(metacls, name, bases): return ConstantNamespace() def __new__(cls, name, bases, classdict): return type.__new__(cls, name, bases, classdict) class A(metaclass=WriteOnceClass): pass -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
In article mailman.2429.1272646255.23598.python-l...@python.org, Jean-Michel Pichavant jeanmic...@sequans.com wrote: Jabapyth wrote: At least a few times a day I wish python had the following shortcut syntax: vbl.=func(args) this would be equivalent to vbl = vbl.func(args) example: foo = Hello world foo.=split( ) print foo # ['Hello', 'world'] and I guess you could generalize this to vbl.=[some text] # vbl = vbl.[some text] e.g. temp.=children[0] # temp = temp.children[0] thoughts? Useless if you use meaningful names for your variables attributes. It may happen that one object attribute refer to an object of the same type, but it is quite rare that both can share the same name anyway. Possible use cases: 1/ car = Car() car = car.wheel # ??? 2/ wheel = Car() # ??? wheel = wheel.wheel # ??? 3/ currentCar = Car() currentCar = currentCar.nextCar The syntax you prose will be applicable on very little assignements (use case 3). I'm not sure it's worth it. Note how related it is to the requirement to have a _radd_ operator. It amounts to the argument that a op= b requires that a and b have somewhat similar type, or that the type of a doesn't really change as a result from the operation. This is IMHO an argument against the .= pseudo-operator. JM Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. alb...@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
* Terry Reedy: * Alf P. Steinbach: * 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. Testing: test lang=py3 t = ([], [], []) t ([], [], []) t[0] += [blah] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment t (['blah'], [], []) _ /test Yep, it matters. Is this change-but-raise-exception a bug? I seem to have a knack for running into bugs. :-) 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. OK. But I think it would be less confusing, less breaking of expectations, if, for the example above, += reduced to the functionality of extend(), with no x. Cheers, thanks, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
Hay I got a better idea. If you put two dots (..) on a line by itself it means execute the previous line again! On 1 May 2010 07:08, Patrick Maupin pmau...@gmail.com wrote: On Apr 30, 11:04 am, Jabapyth jabap...@gmail.com wrote: At least a few times a day I wish python had the following shortcut syntax: vbl.=func(args) this would be equivalent to vbl = vbl.func(args) example: foo = Hello world foo.=split( ) print foo # ['Hello', 'world'] and I guess you could generalize this to vbl.=[some text] # vbl = vbl.[some text] e.g. temp.=children[0] # temp = temp.children[0] thoughts? First thought: good luck getting something like this through. Probably not going to happen, although I do find the idea very intriguing. Second thought: I don't like the proposed syntax at all. +=, -=, /=, *=, etc. conceptually (and, if lhs object supports in- place operator methods, actually) *modify* the lhs object. Your proposed .= syntax conceptually *replaces* the lhs object (actually, rebinds the lhs symbol to the new object). If this were to be deemed worthy of the language, I would think a better syntax would be something like: mystring = .upper() mystring = .replace('a', 'b') etc. The '=' shows clearly that mystring is being rebound to a new object. As Steven has shown, '.' functions as an operator, so if this change were accepted, in reality you would probably be able to write: mystring = . upper() mystring=.upper() or whatever. But the canonical form would probably be with a space before the period but not after. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On 05/01/2010 12:08 AM, Patrick Maupin wrote: +=, -=, /=, *=, etc. conceptually (and, if lhs object supports in- place operator methods, actually) *modify* the lhs object. Your proposed .= syntax conceptually *replaces* the lhs object (actually, rebinds the lhs symbol to the new object). The += family of operators really do rebind the symbol, not modify the object. from decimal import Decimal d = Decimal(42) e = Decimal(18) orig = d d += e d Decimal(60) e Decimal(18) orig Decimal(42) d is orig False If your suggestion that += *modifies* the object, then orig would now unintuitively contain 60 and d is orig would return True. This doesn't preclude you from implementing a self-mutating += style __add__ method and returning self, but it's usually a bad idea unless it's dire for performance (and even then, think it over a couple times). -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
Tim Chase, 01.05.2010 14:13: On 05/01/2010 12:08 AM, Patrick Maupin wrote: +=, -=, /=, *=, etc. conceptually (and, if lhs object supports in- place operator methods, actually) *modify* the lhs object. Your proposed .= syntax conceptually *replaces* the lhs object (actually, rebinds the lhs symbol to the new object). The += family of operators really do rebind the symbol, not modify the object. from decimal import Decimal d = Decimal(42) e = Decimal(18) orig = d d += e d Decimal(60) e Decimal(18) orig Decimal(42) d is orig False If your suggestion that += *modifies* the object, then orig would now unintuitively contain 60 and d is orig would return True. This doesn't preclude you from implementing a self-mutating += style __add__ method and returning self, but it's usually a bad idea unless it's dire for performance (and even then, think it over a couple times). It's not like this was unprecedented in Python, though: Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. l = [1,2,3] a = l l += [4,5,6] l [1, 2, 3, 4, 5, 6] a [1, 2, 3, 4, 5, 6] And I'm pretty sure this wasn't just done for performance reasons. Mutable data types behave that way. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On 01.05.2010 14:13, * Tim Chase: On 05/01/2010 12:08 AM, Patrick Maupin wrote: +=, -=, /=, *=, etc. conceptually (and, if lhs object supports in- place operator methods, actually) *modify* the lhs object. Your proposed .= syntax conceptually *replaces* the lhs object (actually, rebinds the lhs symbol to the new object). The += family of operators really do rebind the symbol, not modify the object. from decimal import Decimal d = Decimal(42) e = Decimal(18) orig = d d += e d Decimal(60) e Decimal(18) orig Decimal(42) d is orig False If your suggestion that += *modifies* the object, then orig would now unintuitively contain 60 and d is orig would return True. In some cases += modifies the object. For CPython this is an optimization for the 'str' type, reducing to O(n) time the common newbie O(n^2) loops. The criterion for doing it is that there is exactly 1 reference (as is the case after a first append, subsequent appends can just modify). This doesn't preclude you from implementing a self-mutating += style __add__ method and returning self, but it's usually a bad idea unless it's dire for performance (and even then, think it over a couple times). Agreed, at the Python level one doesn't in general have the necessary information to do it safely. Nothwithstanding the current CPython and Jython documentation error of sys.getrefcount (or whatever the name was) that indicates that it's available in any implementation. Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
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. 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: a = MyClass() b = MyClass() print a . b I've often wanted to figure out a way to (ab)use python's dot operator for function composition (i.e. f.g(x) == f(g(x)) ). There's no way to do it, not without being way too hackish. OTOH, doing so is quite trivial with regular operators. In short, unless there's __rgetattr__ and unless you can refer to the right-hand operand as an object[1], dot doesn't quack like an operator. [1] well, technically string is an object, but you get what I mean -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On May 1, 7:13 am, Tim Chase t...@thechases.com wrote: On 05/01/2010 12:08 AM, Patrick Maupin wrote: +=, -=, /=, *=, etc. conceptually (and, if lhs object supports in- place operator methods, actually) *modify* the lhs object. Your proposed .= syntax conceptually *replaces* the lhs object (actually, rebinds the lhs symbol to the new object). The += family of operators really do rebind the symbol, not modify the object. from decimal import Decimal d = Decimal(42) e = Decimal(18) orig = d d += e d Decimal(60) e Decimal(18) orig Decimal(42) d is orig False If your suggestion that += *modifies* the object, then orig would now unintuitively contain 60 and d is orig would return True. Well, I wrote conceptually (which I believe is true; it's certainly true for me) and sometimes actually (which I know is true): x = [1,2,3,4,5] y = x x += [6] y [1, 2, 3, 4, 5, 6] x = set() y = x x |= set([1]) y set([1]) SO, if you find those results unintuitive, perhaps you should upgrade your understanding of python. Personally, I don't find any of the results I gave, or the results you gave, surprising, so I'm not saying my conceptually and sometimes actually modifies the result is right for *you* but it works great for me. :-) This doesn't preclude you from implementing a self-mutating += style __add__ method and returning self, but it's usually a bad idea unless it's dire for performance (and even then, think it over a couple times). Well, you should submit a bug report to fix the operation of lists and sets for a starter. But first, you might want to read PEP 203 -- augmented assignments. I particularly like the section which says: The idea behind augmented assignment in Python is that it isn't just an easier way to write the common practice of storing the result of a binary operation in its left-hand operand, but also a way for the left- hand operand in question to know that it should operate `on itself', rather than creating a modified copy of itself. There are a lot of sections which have a similar flavor. If (which I doubt), the augmented dot is accepted, it won't necessarily have the same meaning. x = x.foo could replace x with any other kind of object, and I view it as a replacement, while I view x += foo as a modification. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Sun, 02 May 2010 05:08:53 +1000 Lie Ryan lie.1...@gmail.com 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 Hi. Please watch the attributions. I didn't write that. I was the one who said that '.' was not an operator. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
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)? And __neg__, __pos__ and __inv__ (for the unary - + and ~ operators)? And the three-argument form of __pow__ for power(1, 2, x)? 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). Also, the implementation of attribute lookup is quite complex, with all sorts of special cases and optimizations. a = MyClass() b = MyClass() print a . b I've often wanted to figure out a way to (ab)use python's dot operator for function composition (i.e. f.g(x) == f(g(x)) ). There's no way to do it, not without being way too hackish. That's a good example of where the difference does make a difference. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote: On 05/01/2010 12:08 AM, Patrick Maupin wrote: +=, -=, /=, *=, etc. conceptually (and, if lhs object supports in- place operator methods, actually) *modify* the lhs object. Your proposed .= syntax conceptually *replaces* the lhs object (actually, rebinds the lhs symbol to the new object). The += family of operators really do rebind the symbol, not modify the object. They potentially do both, depending on the object, even for built-ins. from decimal import Decimal [...] I'm not sure why you took the trouble to import Decimal for this example, when you could have shown the same thing with built-ins int or float. All three types are immutable. A counter example with a mutable type: a = [] b = a a += [2] a [2] b [2] thus demonstrating that __iadd__ modifies in place as well as rebinds for at least one mutable type. This doesn't preclude you from implementing a self-mutating += style __add__ method and returning self, but it's usually a bad idea Obviously the Python dev team don't agree with that :) Just to prove that += for lists is not an accident: a = set() b = a a |= set([1]) a set([1]) b set([1]) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Sat, May 1, 2010 at 6:32 PM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote: This doesn't preclude you from implementing a self-mutating += style __add__ method and returning self, but it's usually a bad idea Obviously the Python dev team don't agree with that :) Just to prove that += for lists is not an accident: a = set() b = a a |= set([1]) a set([1]) b set([1]) In both cases, __iOP__ operator methods are being used, not vanilla __OP__ methods, so neither of your examples are relevant to Mr. Chase's point. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Sat, 01 May 2010 19:03:04 -0700, Chris Rebert wrote: On Sat, May 1, 2010 at 6:32 PM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote: This doesn't preclude you from implementing a self-mutating += style __add__ method and returning self, but it's usually a bad idea Obviously the Python dev team don't agree with that :) Just to prove that += for lists is not an accident: [...] In both cases, __iOP__ operator methods are being used, not vanilla __OP__ methods, so neither of your examples are relevant to Mr. Chase's point. I'm sorry, I read Tim's reference to __add__ (instead of __iadd__) as a typo. Having __add__ mutate self would be a strange thing to do. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On May 1, 9:03 pm, Chris Rebert c...@rebertia.com wrote: In both cases, __iOP__ operator methods are being used, not vanilla __OP__ methods, so neither of your examples are relevant to Mr. Chase's point. Well, Tim's main assertion was: The += family of operators really do rebind the symbol, not modify the object. So, using __iadd__ to disprove this blanket assertion is certainly relevant. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
In article 4bdcd631$0$27782$c3e8...@news.astraweb.com, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote: The += family of operators really do rebind the symbol, not modify the object. They potentially do both, depending on the object, even for built-ins. No, they always rebind; sometimes they modify the object and sometimes they rebind the original target to the same object. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ It is easier to optimize correct code than to correct optimized code. --Bill Harlan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On 02.05.2010 06:06, * Aahz: In article4bdcd631$0$27782$c3e8...@news.astraweb.com, Steven D'Apranost...@remove-this-cybersource.com.au wrote: On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote: The += family of operators really do rebind the symbol, not modify the object. They potentially do both, depending on the object, even for built-ins. No, they always rebind; sometimes they modify the object If they always rebind and sometimes modify object then they potentially do both, and so the No at the start of the sentence contradicts this later part. and sometimes they rebind the original target to the same object. At the Python level that seems to be an undetectable null-operation. 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. Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Sat, May 1, 2010 at 10:05 PM, Alf P. Steinbach al...@start.no wrote: On 02.05.2010 06:06, * Aahz: In article4bdcd631$0$27782$c3e8...@news.astraweb.com, Steven D'Apranost...@remove-this-cybersource.com.au wrote: On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote: The += family of operators really do rebind the symbol, not modify the object. They potentially do both, depending on the object, even for built-ins. No, they always rebind; sometimes they modify the object If they always rebind and sometimes modify object then they potentially do both, and so the No at the start of the sentence contradicts this later part. and sometimes they rebind the original target to the same object. At the Python level that seems to be an undetectable null-operation. 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. There are some circumstances where the subtle distinction matters. Consider x.y += z where x is an instance of a class that overrides __setattr__ and __getattribute__ and x.y results in a mutable object. Not doing the assignment can result in a noticeable difference in behavior since __setattr__ won't get called. Yes, this is a slightly obscure case, but it does come up. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Python dot-equals (syntax proposal)
At least a few times a day I wish python had the following shortcut syntax: vbl.=func(args) this would be equivalent to vbl = vbl.func(args) example: foo = Hello world foo.=split( ) print foo # ['Hello', 'world'] and I guess you could generalize this to vbl.=[some text] # vbl = vbl.[some text] e.g. temp.=children[0] # temp = temp.children[0] thoughts? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
That's kind of a nifty idea. However, python is currently under a syntax moratorium. No syntax changes will be accepted for at least 24 months starting from the release date of Python 3.1. See more details here: http://www.python.org/dev/peps/pep-3003/ Cheers, Cliff On Fri, 2010-04-30 at 09:04 -0700, Jabapyth wrote: At least a few times a day I wish python had the following shortcut syntax: vbl.=func(args) this would be equivalent to vbl = vbl.func(args) example: foo = Hello world foo.=split( ) print foo # ['Hello', 'world'] and I guess you could generalize this to vbl.=[some text] # vbl = vbl.[some text] e.g. temp.=children[0] # temp = temp.children[0] thoughts? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
J. Cliff Dyer, 30.04.2010 18:20: On Fri, 2010-04-30 at 09:04 -0700, Jabapyth wrote: At least a few times a day I wish python had the following shortcut syntax: vbl.=func(args) this would be equivalent to vbl = vbl.func(args) example: foo = Hello world foo.=split( ) print foo # ['Hello', 'world'] and I guess you could generalize this to vbl.=[some text] # vbl = vbl.[some text] e.g. temp.=children[0] # temp = temp.children[0] thoughts? That's kind of a nifty idea. However, python is currently under a syntax moratorium. No syntax changes will be accepted for at least 24 months starting from the release date of Python 3.1. See more details here: http://www.python.org/dev/peps/pep-3003/ In any case, the right place to discuss this is the python-ideas list. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Fri, 30 Apr 2010 09:04:59 -0700 (PDT) Jabapyth jabap...@gmail.com wrote: foo = Hello world foo.=split( ) Isn't; foo = Hello world bar = foo.split() # side note - split() splits on whitespace by default so much clearer? Do you really want to see Python turn into Perl? However, if you really want to propose this you should be clear about which of the following you mean. foo .= split() or foo. = split() I assume you mean the former to be analagous to += and friends but I am not sure since . isn't an operator. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
Jabapyth wrote: At least a few times a day I wish python had the following shortcut syntax: vbl.=func(args) this would be equivalent to vbl = vbl.func(args) example: foo = Hello world foo.=split( ) print foo # ['Hello', 'world'] Extending a language comes at a cost, too. A language with 1000 superb features will be much harder to use than one with 10 or 20. In that spirit I suggest a thought experiment: which two features would you kick out of Python to get your new one in? Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
Jabapyth wrote: At least a few times a day I wish python had the following shortcut syntax: vbl.=func(args) this would be equivalent to vbl = vbl.func(args) example: foo = Hello world foo.=split( ) print foo # ['Hello', 'world'] and I guess you could generalize this to vbl.=[some text] # vbl = vbl.[some text] e.g. temp.=children[0] # temp = temp.children[0] thoughts? Useless if you use meaningful names for your variables attributes. It may happen that one object attribute refer to an object of the same type, but it is quite rare that both can share the same name anyway. Possible use cases: 1/ car = Car() car = car.wheel # ??? 2/ wheel = Car() # ??? wheel = wheel.wheel # ??? 3/ currentCar = Car() currentCar = currentCar.nextCar The syntax you prose will be applicable on very little assignements (use case 3). I'm not sure it's worth it. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
D'Arcy J.M. Cain da...@druid.net writes: On Fri, 30 Apr 2010 09:04:59 -0700 (PDT) Jabapyth jabap...@gmail.com wrote: foo = Hello world foo.=split( ) Isn't; foo = Hello world bar = foo.split() # side note - split() splits on whitespace by default so much clearer? Do you really want to see Python turn into Perl? Oh, boy, there we go again. Can you and your buddies please refrain from using Perl as a kind of uber-argument? Just write why you think it's wrong. Bonus points if you can use Python in your arguments. Why I am asking this is that most Oh, like Perl statements I've seen the past months were made by people who either haven't used Perl themselves or have very little skill in the language. This is a Python group. On top of that, it's not possible in Perl (heh, no surprise there). The only thing that comes close is: for ( $a_very_long_variable_name ) { s/foo/bar/g; s/baz/woot/g; s/o+/i/g; } Which makes $_ an alias for $a_very and since s/// defaults to $_ this works. -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Fri, Apr 30, 2010 at 10:05 AM, John Bokma j...@castleamber.com wrote: D'Arcy J.M. Cain da...@druid.net writes: On Fri, 30 Apr 2010 09:04:59 -0700 (PDT) Jabapyth jabap...@gmail.com wrote: foo = Hello world foo.=split( ) Isn't; foo = Hello world bar = foo.split() # side note - split() splits on whitespace by default so much clearer? Do you really want to see Python turn into Perl? Oh, boy, there we go again. Can you and your buddies please refrain from using Perl as a kind of uber-argument? Just write why you think it's wrong. Bonus points if you can use Python in your arguments. Why I am asking this is that most Oh, like Perl statements I've seen the past months were made by people who either haven't used Perl themselves or have very little skill in the language. This is a Python group. On top of that, it's not possible in Perl (heh, no surprise there). The only thing that comes close is: Actually/ironically, it does appear to be in Perl 6: Mutating method call $obj.=meth The .= operator does inplace modification of the object on the left. -- Synopsis 3: Perl 6 Operators (http://feather.perl6.nl/syn/S03.html) Cheers, Chris -- One phrase: Periodic Table of the Operators http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Fri, 30 Apr 2010 12:05:49 -0500 John Bokma j...@castleamber.com wrote: D'Arcy J.M. Cain da...@druid.net writes: so much clearer? Do you really want to see Python turn into Perl? Oh, boy, there we go again. Can you and your buddies please refrain from using Perl as a kind of uber-argument? Just write why you think it's wrong. Bonus points if you can use Python in your arguments. I think I was clear that the problem was obfuscation which Perl is very good at. Haven't you ever had a Perl programmer show you a snippet of code and say I bet you can't guess what this does? On top of that, it's not possible in Perl (heh, no surprise there). The only thing that comes close is: for ( $a_very_long_variable_name ) { s/foo/bar/g; s/baz/woot/g; s/o+/i/g; } Which makes $_ an alias for $a_very and since s/// defaults to $_ I hope that this example wasn't supposed to be a proof of Perl's readability. Anyway, you are right. I just happen to be dealing with some Perl and, even worse, PHP issues on a new server and I am feeling a little battered. I'll be better in a day or two. By the way, to get back to the original topic, I don't really mind if this makes it into the language because I won't be forced to use it. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On 05/01/10 02:50, Jean-Michel Pichavant wrote: Jabapyth wrote: At least a few times a day I wish python had the following shortcut syntax: snip currentCar = Car() currentCar = currentCar.nextCar The syntax you prose will be applicable on very little assignements (use case 3). I'm not sure it's worth it. And for the last use case, isn't iterator better? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
Chris Rebert c...@rebertia.com writes: On Fri, Apr 30, 2010 at 10:05 AM, John Bokma j...@castleamber.com wrote: [..] On top of that, it's not possible in Perl (heh, no surprise there). The only thing that comes close is: Actually/ironically, it does appear to be in Perl 6: Mutating method call $obj.=meth The .= operator does inplace modification of the object on the left. -- Synopsis 3: Perl 6 Operators (http://feather.perl6.nl/syn/S03.html) I stand correct, thanks. -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
In article 87zl0klvki@castleamber.com, John Bokma j...@castleamber.com wrote: Why I am asking this is that most Oh, like Perl statements I've seen the past months were made by people who either haven't used Perl themselves or have very little skill in the language. What evidence do you have for your assertion? -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ It is easier to optimize correct code than to correct optimized code. --Bill Harlan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Apr 30, 9:04 am, Jabapyth jabap...@gmail.com wrote: At least a few times a day I wish python had the following shortcut syntax: vbl.=func(args) this would be equivalent to vbl = vbl.func(args) example: foo = Hello world foo.=split( ) print foo # ['Hello', 'world'] and I guess you could generalize this to vbl.=[some text] # vbl = vbl.[some text] e.g. temp.=children[0] # temp = temp.children[0] thoughts? I tend to use this design pattern occasionally in my code as well: val = val.func() PROPOSED: val .= func() OR val = func(val) PROPOSED: val .= func(?) (not really sure how this should look) However, these are the only two use cases I can think of for this language syntax modification proposal. The first use case could lead to namespace issues (if func() exists as a function as well as a method), and even if the interpreter can choose correctly, reading it may lead to confusion. There will be at least some ambiguity in the second use case (what if func() takes more than one argument, what if it requires keyword arguments?). The current implementation is much more readable (THE guiding principle with python), and doesn't require any lengthier code than the proposed changes, especially when you factor in any other syntax changes that would be necessary to handle the aforementioned ambiguities. Just my 2 cents. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Fri, 30 Apr 2010 18:50:46 +0200, Jean-Michel Pichavant wrote: Jabapyth wrote: At least a few times a day I wish python had the following shortcut syntax: vbl.=func(args) this would be equivalent to vbl = vbl.func(args) [...] Useless if you use meaningful names for your variables attributes. It may happen that one object attribute refer to an object of the same type, but it is quite rare that both can share the same name anyway. How about these common operations? my_string = my_string.replace('quite rare', 'very common') my_string = my_string.upper() my_string = my_string.strip() my_dict = my_dict.copy() Or from decimal, a whole lot of methods that return new decimals, including: to_integral, next_plus, canonical, ln, sqrt, and many others. But regardless of whether the pattern x = x.method is common or rare, I don't like the suggestion, I don't think it's necessary, and because of the moratorium it isn't going to happen any time soon even if Guido himself suggests it. -1 for the suggested .= syntactic sugar. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Fri, 30 Apr 2010 12:34:34 -0400, D'Arcy J.M. Cain wrote: I assume you mean the former to be analagous to += and friends but I am not sure since . isn't an operator. It's a de facto operator. If you google on python dot operator you will find many people who refer to it as such, and attribute lookup can be over-ridden at runtime (using __getattribute__, __getattr__, etc.) just like operators +, -, * etc. Also you can do this: s = something s . upper() 'SOMETHING' (s+ else) . upper() 'SOMETHING ELSE' And even apply the dot operator to floats and ints, although because of the ambiguity with floats you need to be clever: 1.2.is_integer() False 4 .numerator 4 However, dot is not a real operator, whatever that means: internally, CPython treats it as a delimiter: http://docs.python.org/reference/lexical_analysis.html#operators 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dot-equals (syntax proposal)
On Apr 30, 11:04 am, Jabapyth jabap...@gmail.com wrote: At least a few times a day I wish python had the following shortcut syntax: vbl.=func(args) this would be equivalent to vbl = vbl.func(args) example: foo = Hello world foo.=split( ) print foo # ['Hello', 'world'] and I guess you could generalize this to vbl.=[some text] # vbl = vbl.[some text] e.g. temp.=children[0] # temp = temp.children[0] thoughts? First thought: good luck getting something like this through. Probably not going to happen, although I do find the idea very intriguing. Second thought: I don't like the proposed syntax at all. +=, -=, /=, *=, etc. conceptually (and, if lhs object supports in- place operator methods, actually) *modify* the lhs object. Your proposed .= syntax conceptually *replaces* the lhs object (actually, rebinds the lhs symbol to the new object). If this were to be deemed worthy of the language, I would think a better syntax would be something like: mystring = .upper() mystring = .replace('a', 'b') etc. The '=' shows clearly that mystring is being rebound to a new object. As Steven has shown, '.' functions as an operator, so if this change were accepted, in reality you would probably be able to write: mystring = . upper() mystring=.upper() or whatever. But the canonical form would probably be with a space before the period but not after. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list