[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