[Python-ideas] Allow using ** twice

[Haoyi Li]

> 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.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130606/cb0fe4d1/attachment-0001.html>