[PEP 203] Augmented Assignment

Aahz Maruch aahz at netcom.com
Mon Aug 14 14:36:21 EDT 2000


There are a number of typos; I'm correcting those in-line.  My biggest
question has to do with the requirement to INCREF() the returned object
in extensions; I'm assuming that Python internally does a DECREF()
because the variable has been "assigned" to a new object?

I'll also vote for __<op>_inplace__, but I'll settle for
__inplace_<op>__.


In article <20000814180327.U14470 at xs4all.nl>,
Thomas Wouters  <thomas at xs4all.net> wrote:
>
>PEP: 203
>Title: Augmented Assignments
>Version: $Revision: 1.5 $
>Owner: thomas at xs4all.net (Thomas Wouters)
>Python-Version: 2.0
>Status: Draft
>Created: 13-Jul-2000
>Type: Standard

>    This PEP describes the `augmented assignment' proposal for Python
>    2.0.  This PEP tracks the status and ownership of this feature,
>    slated for introduction in Python 2.0.  It contains a description
>    of the feature and outlines changes necessary to support the
>    feature.  This PEP summarizes discussions held in mailing list
>    forums, and provides URLs for further information, where
>    appropriate.  The CVS revision history of this file contains the
>    definitive historical record.

"information where appropriate" (no comma)

>    They implement the same operator as their normal binary form,
>    except that the operation is done `in-place' when the left-hand
>    side object supports it, and that the left-hand side is only
>    evaluated once.

I'm wondering whether "mutable" should go in there somehow?

>    So, given an instance object `x', the expression
>    
>        x += y
>    
>    tries to call x.__add_ab__(y), which is the `in-place' variant of
>    __add__. If __add_ab__ is not present, x.__add__(y) is
>    attempted, and finally y.__radd__(x) if __add__ is missing too. 
>    There is no `right-hand-side' variant of __add_ab__, because that
>    would require for `y' to know how to in-place modify `x', which is
>    an unsafe to say the least. The __add_ab__ hook should behave exactly
>    like __add__, returning the result of the operation (which could
>    be `self') which is to be stored in the variable `x'.

s/which is an unsafe/which is unsafe/

>    Adding augmented assignment will make Pythons syntax more complex. 
>    Instead of a single assignment operation, there are now twelve
>    assignment operations, eleven of which also perform an binary
>    operation. However, these eleven new forms of assignment are easy
>    to understand as the coupling between assignment and the binary
>    operation, and they require no large conceptual leap to
>    understand. Furthermore, languages that do have augmented
>    assignment have shown that they are a popular, much used feature.

s/Pythons/Python's/

>    Expressions of the form
>    
>        <x> = <x> <operator> <y>
>        
>    are common enough in those languages to make the extra syntax
>    worthwhile, and Python does not have significantly less of those
>    expressions. Quite the opposite, in fact, since in Python you can
>    also concatenate lists with a binary operator, something that is
>    done quite frequently. Writing the above expression as

s/significantly less/significantly fewer/

(General rule of thumb: "fewer" is used for discrete objects, "less" for
continuously variable objects.  So, "weighs less" but "fewer people".)

>    To work around this problem, the packages currently have to use
>    methods or functions to modify an object in-place, which is
>    definately less readable than an augmented assignment expression. 

s/definately/definitely/

>    Augmented assignment won't solve all the problems for these
>    packages, since some operations cannot be expressed in the limited
>    set of binary operators to start with, but it is a start. A
>    different PEP[3] is looking at adding new operators.

Missing third footnote.

>    For C extention types, the following struct members are added:

s/extention/extension/
--
                      --- Aahz (Copyright 2000 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

Gun-toting Naderite / socialized medicine libertarian



More information about the Python-list mailing list