[Python-checkins] peps: Fixed some spelling errors and inconsistent quoting, rewrote some unclear
georg.brandl
python-checkins at python.org
Wed Mar 23 21:24:41 CET 2011
http://hg.python.org/peps/rev/2e0b7c812bf4
changeset: 89:2e0b7c812bf4
user: Thomas Wouters <thomas at python.org>
date: Mon Aug 14 15:22:52 2000 +0000
summary:
Fixed some spelling errors and inconsistent quoting, rewrote some unclear
parts and added a Rationale and an Open Issues section. Is this something
like you had in mind when you say 'Rationale', Tim ? :-)
files:
pep-0203.txt | 133 +++++++++++++++++++++++++++++++++-----
1 files changed, 114 insertions(+), 19 deletions(-)
diff --git a/pep-0203.txt b/pep-0203.txt
--- a/pep-0203.txt
+++ b/pep-0203.txt
@@ -4,6 +4,8 @@
Owner: thomas at xs4all.net (Thomas Wouters)
Python-Version: 2.0
Status: Draft
+Created: 13-Jul-2000
+Type: Standard
Introduction
@@ -25,9 +27,10 @@
+= -= *= /= %= **= <<= >>= &= ^= |=
- They implement the same operator as their normal binary form, with
- the exception that the operation is done `in-place' whenever
- possible.
+ 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.
They truly behave as augmented assignment, in that they perform
all of the normal load and store operations, in addition to the
@@ -35,16 +38,16 @@
x += y
- The object `x' is loaded, then added with 1, and the resulting
- object is stored back in the original place. The precise action
- performed on the two arguments depends on the type of `x', and
- possibly of `y'.
+ The object `x' is loaded, then `y' is added to it, and the
+ resulting object is stored back in the original place. The precise
+ action performed on the two arguments depends on the type of `x',
+ and possibly of `y'.
The idea behind augmented assignment in Python is that it isn't
just an easier way to write the common practice of storing the
result of a binary operation in its left-hand operand, but also a
way for the left-hand operand in question to know that it should
- operate 'on itself', rather than creating a modified copy of
+ operate `on itself', rather than creating a modified copy of
itself.
To make this possible, a number of new `hooks' are added to Python
@@ -58,12 +61,12 @@
x += y
- tries to call x.__add_ab__(y), which is the 'in-place' variant of
+ 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 assumption. The __add_ab__ hook should behave exactly
+ 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'.
@@ -76,6 +79,59 @@
should be INCREF()'d appropriately.
+Rationale
+
+ There are two main reasons for adding this feature to Python:
+ simplicity of expression, and support for in-place operations. The
+ end result is a tradeoff between simplicity of syntax and
+ simplicity of expression; like most new features, augmented
+ assignment doesn't add anything that was previously impossible. It
+ merely makes these things easier to do.
+
+ 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.
+ 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
+
+ <x> <operator>= <y>
+
+ is both more readable and less error prone, because it is
+ instantly obvious to the reader that it is <x> that is being
+ changed, and not <x> that is being replaced by something almost,
+ but not quite, entirely unlike <x>.
+
+ The new in-place operations are especially useful to matrix
+ calculation and other applications that require large objects. In
+ order to efficiently deal with the available program memory, such
+ packages cannot blindly use the current binary operations. Because
+ these operations always create a new character, adding a single
+ item to an existing (large) object would result in copying the
+ entire object (which may cause the application to run out of
+ memory), add the single item, and then possibly delete the
+ original object, depending on reference count.
+
+ 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.
+ 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.
+
+
New methods
The proposed implementation adds the following 11 possible `hooks'
@@ -94,9 +150,10 @@
__xor_ab__
__or_ab__
- The `__add_ab__' name is one proposed by Guido[1], and stands for `and
- becomes'. Other proposed names include '__iadd__', `__add_in__'
- `__inplace_add__'
+ The `__add_ab__' name is one proposed by Guido[1], and stands for
+ `and becomes'. Other proposed names include `__iadd__',
+ `__add_in__' and `__inplace_add__'. A firm decision by the BDFL is
+ probably needed to finalize this issue.
For C extention types, the following struct members are added:
@@ -122,7 +179,8 @@
allocated room for these slots. Until a clean break in binary
compatibility is made (which may or may not happen before 2.0)
code that wants to use one of the new struct members must first
- check that they are available with the 'PyType_HasFeature()' macro:
+ check that they are available with the `PyType_HasFeature()'
+ macro:
if (PyType_HasFeature(x->ob_type, Py_TPFLAGS_HAVE_INPLACE_OPS) &&
x->ob_type->tp_as_number && x->ob_type->tp_as_number->nb_inplace_add) {
@@ -176,21 +234,21 @@
DUP_TOPX
The INPLACE_* bytecodes mirror the BINARY_* bytecodes, except that
- they are implemented as calls to the 'InPlace' API functions. The
- other two bytecodes are 'utility' bytecodes: ROT_FOUR behaves like
+ they are implemented as calls to the `InPlace' API functions. The
+ other two bytecodes are `utility' bytecodes: ROT_FOUR behaves like
ROT_THREE except that the four topmost stack items are rotated.
DUP_TOPX is a bytecode that takes a single argument, which should
be an integer between 1 and 5 (inclusive) which is the number of
items to duplicate in one block. Given a stack like this (where
- the left side of the list is the 'top' of the stack):
+ the right side of the list is the `top' of the stack):
- [a, b, c, d, e, f, g]
+ [1, 2, 3, 4, 5]
"DUP_TOPX 3" would duplicate the top 3 items, resulting in this
stack:
- [a, b, c, d, e, f, g, e, f, g]
+ [1, 2, 3, 4, 5, 3, 4, 5]
DUP_TOPX with an argument of 1 is the same as DUP_TOP. The limit
of 5 is purely an implementation limit. The implementation of
@@ -199,6 +257,43 @@
number of DUP_TOP and ROT_*.
+Open Issues
+
+ The PyNumber_InPlacePower() function only takes two arguments, not
+ one like PyNumber_Power(). This is because there is no way to do
+ an inplace three-argument-power trough the augmented assignment
+ syntax or the power() function.
+
+
+ Possibly a more obvious name for the Python hooks can be found.
+ `_ab_' is what Guido proposed[1] as a working name, and comes from
+ an old Algol-68 naming convention.
+
+
+ Documentation needs to be written. The reference manual, the `dis'
+ section of the library manual, and possibly the tutorial.
+
+
+ The DUP_TOPX bytecode is a conveniency bytecode, and is not
+ actually necessary. It should be considered whether this bytecode
+ is worth having. There seems to be no other possible use for this
+ bytecode at this time.
+
+
+ The standard library should be adjusted to provide augmented
+ assignment hooks, where sensible.
+
+
+ It is not possible to do an inplace operation in the variant of
+
+ <builtin type> += <instance object>
+
+ Instead, the instance objects' __radd__ hook is called, with the
+ builtin type as argument. The same goes for the other operations.
+ It might necessary to add a right-hand version of __add_ab__ after
+ all, to support something like that.
+
+
Copyright
This document has been placed in the public domain.
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list