User-defined augmented assignment

Discussion in 'Python' started by Pierre Barbier de Reuille, Sep 29, 2005.

  1. Hello,

    a discussion began on python-dev about this. It began by a bug report,
    but is shifted and it now belongs to this discussion group.

    The problem I find with augmented assignment is it's too complex, it's
    badly explained, it's error-prone. And most of all, I don't see any
    use-case for it !

    The most common error is to consider that :

    a += b <==> a.__iadd__(b)

    when the truth is :

    a += b <==> a = a.__iadd__(b)

    which can be very confusing, as the two "a" are not necessarily the
    same. It then leads to subtle errors like:

    >>> class A(object):
    >>> a = 0


    >>> a = A()
    >>> b = A()
    >>> a.a += 1
    >>> A.a += 2
    >>> print a.a

    1
    >>> print b.a

    2

    Also, the following behavior is pretty confusing :

    >>> a = [1]
    >>> b = [a]
    >>> c = (a,)
    >>> b[0] += [2] # Ok, no pb
    >>> print a

    [1,2]
    >>> c[0] += [3]

    Traceback (most recent call last):
    File "<string>", line 1, in ?
    TypeError: object doesn't support item assignment
    >>> print a

    [1,2,3]

    Then, in the standard library, there is no use-case of user-defined
    augmented assignment I could find. Of course, I find the augmented
    assignement itself very useful ! I use it a lot with immutable objects
    (strings, numbers, tuples, ...) but I tend to avoid it with mutables,
    and so it seems in the standard library that uses extensively the
    "extend" method of lists and very seldom the "+=" operator with lists.
    And even where the "a+=b" is used, it could be replaced with either
    "a.extend(b)" or "a = a+b" without bugs.

    So, what I would suggest is to drop the user-defined augmented
    assignment and to ensure this equivalence :

    a X= b <=> a = a X b

    with 'X' begin one of the operators.

    Pierre
     
    Pierre Barbier de Reuille, Sep 29, 2005
    #1
    1. Advertising

  2. Pierre Barbier de Reuille wrote:

    > So, what I would suggest is to drop the user-defined augmented
    > assignment and to ensure this equivalence :
    >
    > a X= b <=> a = a X b
    >
    > with 'X' begin one of the operators.


    It can be done, but it's unnecessary for mutable objects like
    sets or lists. A new object must be created in these cases where
    one would suffice.

    Reinhold
     
    Reinhold Birkenfeld, Sep 29, 2005
    #2
    1. Advertising

  3. Reinhold Birkenfeld a écrit :
    > Pierre Barbier de Reuille wrote:
    >
    >
    >>So, what I would suggest is to drop the user-defined augmented
    >>assignment and to ensure this equivalence :
    >>
    >>a X= b <=> a = a X b
    >>
    >>with 'X' begin one of the operators.

    >
    >
    > It can be done, but it's unnecessary for mutable objects like
    > sets or lists. A new object must be created in these cases where
    > one would suffice.


    Well, my point is: the benefit is too small compared to the
    disadvantage. If you really have a mutable (let say a list with +=) then
    you do:

    >>> a.extend(b)


    and there is no interpretation error possible. BTW, that's what's done
    in the standard library ...

    Pierre

    >
    > Reinhold
     
    Pierre Barbier de Reuille, Sep 29, 2005
    #3
  4. Pierre Barbier de Reuille

    Paddy Guest

    I thought along these lines:
    It is an augmented ASSIGNMENT. (It even has an equals sign in it).
    tuples are immutable so you should not be able to assign to one of
    its elements.

    - So there is no problem for me - I shouldn't be messing with an
    element of an
    immutable type!

    - Cheers, Paddy.
     
    Paddy, Sep 29, 2005
    #4
  5. Pierre Barbier de Reuille

    Tom Anderson Guest

    On Thu, 29 Sep 2005, Pierre Barbier de Reuille wrote:

    > a discussion began on python-dev about this. It began by a bug report,
    > but is shifted and it now belongs to this discussion group.
    >
    > The problem I find with augmented assignment is it's too complex, it's
    > badly explained, it's error-prone. And most of all, I don't see any
    > use-case for it !
    >
    > The most common error is to consider that :
    >
    > a += b <==> a.__iadd__(b)
    >
    > when the truth is :
    >
    > a += b <==> a = a.__iadd__(b)
    >
    > which can be very confusing, as the two "a" are not necessarily the
    > same.


    Indeed. I certainly didn't realise that was how it worked.

    > So, what I would suggest is to drop the user-defined augmented
    > assignment and to ensure this equivalence :
    >
    > a X= b <=> a = a X b
    >
    > with 'X' begin one of the operators.


    That seems quite an odd move. Your proposal would lead to even more
    surprising behaviour; consider this:

    a = [1, 2, 3]
    b = a
    a += [4, 5, 6]
    print b

    At present, this prints [1, 2, 3, 4, 5, 6]; if we were to follow your
    suggestion, it would be [1, 2, 3].

    So, -1, i'm afraid.

    I think the right solution here is staring us in the face: if everyone
    seems to think that:

    a += b <==> a.__iadd__(b)

    Then why not make it so that:

    a += b <==> a.__iadd__(b)

    Principle of Least Surprise and all that.

    Since not everything that should support += is mutable (integers, for
    example), how about saying that if the recipient of a += doesn't have an
    __iadd__ method, execution falls back to:

    a = a + b

    I say 'a + b', because that means we invoke __add__ and __radd__
    appropriately; indeed, the __add__ vs __radd__ thing is a precedent for
    this sort of fallback.

    Doesn't that leave everyone happy?

    tom

    --
    I'm not quite sure how that works but I like it ...
     
    Tom Anderson, Oct 2, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Doug Tolton

    Augmented Assignment question

    Doug Tolton, Jul 16, 2003, in forum: Python
    Replies:
    6
    Views:
    490
    John Machin
    Jul 19, 2003
  2. Delaney, Timothy C (Timothy)

    RE: Augmented Assignment question

    Delaney, Timothy C (Timothy), Jul 17, 2003, in forum: Python
    Replies:
    0
    Views:
    399
    Delaney, Timothy C (Timothy)
    Jul 17, 2003
  3. Suresh Jeevanandam

    Augmented assignment

    Suresh Jeevanandam, Feb 21, 2006, in forum: Python
    Replies:
    8
    Views:
    345
    Terry Hancock
    Feb 21, 2006
  4. Josiah Carlson
    Replies:
    4
    Views:
    369
    Boris Borcic
    Jun 19, 2006
  5. Tim N. van der Leeuw

    Nested scopes, and augmented assignment

    Tim N. van der Leeuw, Jul 4, 2006, in forum: Python
    Replies:
    39
    Views:
    810
    Piet van Oostrum
    Jul 10, 2006
Loading...

Share This Page