Re: Re: Python Gotcha's?
On 4/4/2012 7:32 PM, Chris Angelico wrote: Don't know if it's what's meant on that page by the += operator, Yes, it is. a=([1],) a[0].append(2) # This is fine [In the following, I use the term name rather loosely.] The append() method attempts to modify the object whose name is a[0]. That object is a LIST, so the attempt succeeds. a[0]+=[3] # This is not. The assignment attempts to modify the object whose name is a. That object is a TUPLE, so the attempt fails. This might be a surprise, but I'm not sure it deserves to be called a wart. Note the similarity to: temp = a[0] + [3] # succeeds a[0] = temp # fails -John -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Python Gotcha's?
This is not a gotcha, and it's not surprising. As John described, you're assigning a new value to an index of a tuple, which tuples don't support. a[0] += [3] is the same as a[0] = a[0] + [3] which after evaluation is the same as a[0] = [1, 3] You can always modify an item that happens to be in a tuple if the item itself is mutable, but you cannot add, remove, or replace items in a tuple. Michael On Thu, Apr 5, 2012 at 10:15 AM, John Posner jjpos...@optimum.net wrote: On 4/4/2012 7:32 PM, Chris Angelico wrote: Don't know if it's what's meant on that page by the += operator, Yes, it is. a=([1],) a[0].append(2) # This is fine [In the following, I use the term name rather loosely.] The append() method attempts to modify the object whose name is a[0]. That object is a LIST, so the attempt succeeds. a[0]+=[3] # This is not. The assignment attempts to modify the object whose name is a. That object is a TUPLE, so the attempt fails. This might be a surprise, but I'm not sure it deserves to be called a wart. Note the similarity to: temp = a[0] + [3] # succeeds a[0] = temp # fails -John -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Python Gotcha's?
On Fri, Apr 6, 2012 at 4:44 AM, Michael Hrivnak mhriv...@hrivnak.org wrote: This is not a gotcha, and it's not surprising. As John described, you're assigning a new value to an index of a tuple, which tuples don't support. a[0] += [3] is the same as a[0] = a[0] + [3] which after evaluation is the same as a[0] = [1, 3] You can always modify an item that happens to be in a tuple if the item itself is mutable, but you cannot add, remove, or replace items in a tuple. It does make sense, and I've never actually had problems with it myself. But it's come up on the list and clearly been a cause of confusion for people, so I thought it worth mentioning. And, as it turns out, it was the entry already on the list. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Python Gotcha's?
On 4/5/2012 13:24, Chris Angelico wrote: I think this example highlights a major point about gotchas: the difference between an obvious language feature and a gotcha depends on where you come from. To a PHP programmer, 1 and 1 are in many ways indistinguishable. To a C programmer, they're utterly incompatible. I think I agree with this. For instance, I'd consider the fact that this works in Python to be a gotcha: 1 abc True But that's because I like more strongly-typed systems. [I'm most decidedly not trying to start up that discussion again...] This is changed in Python 3: 1 abc Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() str() though you can still compare *some* types I consider logically unorderable: 0 True True I think it also has bearing on the ' vs issue. For instance, I totally think it's not at all surprising that one can be accepted and the other not, or that they behave differently. (Though I *do* find it surprising in the context of JSON given that JS apparently allows either.) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Re: Python Gotcha's?
On 4/5/2012 13:44, Michael Hrivnak wrote: This is not a gotcha, and it's not surprising. As John described, you're assigning a new value to an index of a tuple, which tuples don't support. Um, at least for me personally, yes, it is surprising, and yes, it is a gotcha. This goes back to what languages you're used to. I come from a strong C++ background. In C++, something like mytuple[0] += [3] would wind up calling 'operator+=' on the list, that += would mutate the list, and then the expression would be done. The C++ approach doesn't really work with Python because more stuff is immutable, and Python's behavior is arguably the least-bad solution, but it WAS definitely surprising for me (and others!) when I learned about Python's behavior. In particular, the translation of 'a+=b' to 'temp = a + b; a = temp' is *not* a very natural one to me. Evan Michael On Thu, Apr 5, 2012 at 10:15 AM, John Posner jjpos...@optimum.net wrote: On 4/4/2012 7:32 PM, Chris Angelico wrote: Don't know if it's what's meant on that page by the +=perator, Yes, it is. a=1],) a[0].append(2) # This is fine [In the following, I use the term name rather loosely.] The append() method attempts to modify the object whose name is a[0]. That object is a LIST, so the attempt succeeds. a[0]+=] # This is not. The assignment attempts to modify the object whose name is a. That object is a TUPLE, so the attempt fails. This might be a surprise, but I'm not sure it deserves to be called a wart. Note the similarity to: temp =[0] + [3] # succeeds a[0] =emp # fails -John -- http://mail.python.org/mailman/listinfo/python-list signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
