[Python-ideas] Allow using ** twice

[Peter Jung]

Immutability of an object is defined as the guarantee that the object cannot change state after creation. 

> All the languages which only allow += on immutable values 

therefore is a misinterpretation of the term immutable. 

Example: In C with
int a = 42;
rhe variable a is not immutable per definition because after
a += 1; 
the state did change to 43. 

I'd take "+= is not allowed" as synonymous to "is immutable". 

Anyway, I'd be superglad to have A + B on dicts. My intuition tells, the left operand should be evaluated first, so the keys of B should win. 


Am 06.06.2013 um 20:46 schrieb Haoyi Li <haoyi.sg at gmail.com>:

> > That would make += misleading. In any other language with a += operator, it mutates
> 
> Does it? All the languages which only allow += on immutable values (e.g. Java, C, Javascript) obviously don't mutate anything. C# does a straight desugar into a = a + b. Scala allows you to override it separately, but the vast majority of them (by default) are simple desugars into a = a + b. Not familiar with how C++ does it, perhaps someone could chime in?
> 
> I don't know the answer, but I don't think it's obvious at all that += mutates. What (non-python) background are you coming from where this is common practice?
> 
> Anyway, this is all bikeshedding. Regardless of how the AugAssign operators work, I think that having dict_a + dict_b merge dict_a and dict_b, with dict_a's keys taking precedence, would be a wonderful thing!
> 
> 
> 
> 
> On Thu, Jun 6, 2013 at 2:36 PM, Andrew Barnert <abarnert at yahoo.com> wrote:
>> On Thu, Jun 6, 2013 at 1:40 PM, Markus Unterwaditzer <markus at unterwaditzer.net> wrote:
>> 
>> >> Actually i wouldn't expect += to be the same as dict.update, but it rather would create a new dictionary.
>> 
>> Why? The whole point of += is that it does a mutating in-place addition. That's how it works with all other mutable types; why would it work differently with dict?
>> 
>> The reason we don't have this today is that it's not necessarily clear what "addition" means for dicts; it's completely clear what "mutable addition" would mean if we knew what "addition" meant.
>> 
>> 
>> From: Haoyi Li <haoyi.sg at gmail.com>
>> Sent: Thursday, June 6, 2013 10:53 AM
>> >Yeah, and I didn't expect list_a += list_b to be the same as list_a.extend(list_b) (I've had plenty of bugs from this, too!), but it is. I think dicts should be consistent with lists, even if I'd prefer it if both of them had a += b desugar into a = a + b.
>> 
>> 
>> That would make += misleading. In any other language with a += operator, it mutates. (And pure immutable languages don't have a += operator.) That's why we have __iadd__ and friends in the first place.
>> 
>> In fact, I'd almost prefer it if a += b _never_ desugared into a = a + b (that is, if the default implementation of __iadd__ were to raise NotImplemented instead of to call __add__), but I understand why it's useful for, e.g., teaching novices with integer variables.
>> 
>> 
>> In general, for mutable objects, += is the primitive operation (extend, update, etc.), and + is conceptually "copy, then += the copy". (But of course it's often more efficient or more readable to implement each of them independently.)
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130606/ac3b7b2c/attachment-0001.html>