[Python-checkins] r53831 - peps/trunk/pep-0363.txt

david.goodger python-checkins at python.org
Tue Feb 20 04:30:59 CET 2007

Author: david.goodger
Date: Tue Feb 20 04:30:58 2007
New Revision: 53831

update from the author

Modified: peps/trunk/pep-0363.txt
--- peps/trunk/pep-0363.txt	(original)
+++ peps/trunk/pep-0363.txt	Tue Feb 20 04:30:58 2007
@@ -2,12 +2,12 @@
 Title: Syntax For Dynamic Attribute Access
 Version: $Revision$
 Last-Modified: $Date$
-Author: Ben North <ben at redfrontdoor.org>
-Status: Draft
+Author: Ben North <ben at redfrontdoor.org>
+Status: Rejected
 Type: Standards Track
 Content-Type: text/plain
 Created: 29-Jan-2007
+Post-History: 12-Feb-2007
@@ -28,13 +28,6 @@
         z = getattr(getattr(y, 'foo_%d' % n), 'bar_%s' % s)
-    I wrote this patch mostly to advance my own understanding of and
-    experiment with the python language, but I've written it up in the
-    style of a PEP in case it might be a useful idea.
     Dictionary access and indexing both have a friendly invocation
@@ -64,18 +57,17 @@
           x = getattr(y, 'foo_%d' % n, 0)
     This PEP describes a new syntax for dynamic attribute access ---
-    "x.(expr)" --- with examples given in the Abstract above.  The new
-    syntax also allows the provision of a default value in the "get"
-    case, as in:
+    "x.(expr)" --- with examples given in the Abstract above.
+    (The new syntax could also allow the provision of a default value in
+    the "get" case, as in:
         x = y.('foo_%d' % n, None)
-    This 2-argument form of dynamic attribute access is not permitted as
-    the target of an (augmented or normal) assignment.  Also, this part
-    of the new syntax was not as well received [6] in initial
-    discussions on python-ideas, and I agree that it does not fit so
-    cleanly.  I'm happy to prepare a revised PEP/patch without the
-    2-argument form if the consensus is that this would be preferred.
+    This 2-argument form of dynamic attribute access would not be
+    permitted as the target of an (augmented or normal) assignment.  The
+    "Discussion" section below includes opinions specifically on the
+    2-argument extension.)
     Finally, the new syntax can be used with the "del" statement, as in
@@ -144,80 +136,18 @@
     be a performance penalty of around 1% in the pystones score with the
     patched version.  One suggestion is that this is because the longer
     main loop in ceval.c hurts the cache behaviour, but this has not
-    been confirmed.  (Maybe a tool like valgrind [2] could help here?)
+    been confirmed.
     On the other hand, measurements suggest a speed-up of around 40--45%
     for dynamic attribute access.
-Discussion To Date
-    Initial posting of this PEP in draft form was to python-ideas on
-    20070209 [4], and the response was generally positive:
-        I've thought of the same syntax. I think you should submit this
-        to the PEP editor and argue on Python-dev for its inclusion in
-        Python 2.6 -- there's no benefit that I see of waiting until
-        3.0.  --- Guido van Rossum [5]
-        Wow!  I have to say this is a compelling idea.  The syntax is a
-        bit foreign looking, but [...] I feel like I could learn to like
-        it anyway. --- Greg Falcon [6]
-        I look forward to seeing this in Python 2.6.  --- Josiah
-        Carlson, further down the thread [8]
-    with Greg Falcon expressing the reservations about the 2-argument
-    form already noted above, and Josiah Carlson raising a query about
-    performance:
-        My only concern with your propsed change is your draft
-        implementation. [...]  Specifically, your changes [...] may
-        negatively affect general Python performance.  --- Josiah
-        Carlson [7]
-    Some initial measurements (see above) suggest the performance
-    penalty is small, and Josiah Carlson said of such cost that it
-    "isn't really substantial". [8]
-Questions To Be Resolved
-    * Whether to allow the 2-argument form for default arguments.
-    * Whether the performance impact is real; whether it is acceptable;
-      whether alternative implementations might improve this aspect.
-Alternative Syntax For The New Feature
-    Other syntaxes could be used, for example braces are currently
-    invalid in a "trailer", so could be used here, giving
-        x{'foo_%d' % n} += 1
-    My personal preference is for the
-        x.('foo_%d' % n) += 1
-    syntax though: the presence of the dot shows there is attribute
-    access going on; the parentheses have an analogous meaning to the
-    mathematical "work this out first" meaning.  This is also the
-    syntax used in the language Matlab [1] for dynamic "field" access
-    (where "field" is the Matlab term analogous to Python's
-    "attribute").
-    Discussions on python-ideas (see above) made no comment on the brace
-    alternative, and the .() notation was well-enough received, so the
-    brace alternative should be considered rejected, I think.
 Error Cases
     Only strings are permitted as attribute names, so for instance the
     following error is produced:
-      >>> x.(99) = 8
+     >>> x.(99) = 8
         Traceback (most recent call last):
           File "<stdin>", line 1, in <module>
         TypeError: attribute name must be string, not 'int'
@@ -233,29 +163,78 @@
     compile.c, and three new opcodes (load/store/del) with
     accompanying changes to opcode.h and ceval.c.  The patch consists
     of c.180 additional lines in the core code, and c.100 additional
-    lines of tests.  It is available as sourceforge patch #1657573 [3].
+    lines of tests.  It is available as sourceforge patch #1657573 [1].
-    [1] Using Dynamic Field Names :: Data Types (MATLAB Programming)
-        http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f2-41859.html
-    [2] Valgrind: "suite of tools for debugging and profiling Linux programs"
-        http://www.valgrind.org/
+Mailing Lists Discussion
-    [3] Sourceforge patch #1657573
-        http://sourceforge.net/tracker/index.php?func=detail&aid=1657573&group_id=5470&atid=305470
+    Initial posting of this PEP in draft form was to python-ideas on
+    20070209 [2], and the response was generally positive.  The PEP was
+    then posted to python-dev on 20070212 [3], and an interesting
+    discussion ensued.  A brief summary:
+    Initially, there was reasonable (but not unanimous) support for the
+    idea, although the precise choice of syntax had a more mixed
+    reception.  Several people thought the "." would be too easily
+    overlooked, with the result that the syntax could be confused with a
+    method/function call.  A few alternative syntaxes were suggested:
+        obj.(foo)
+        obj.[foo]
+        obj.{foo}
+        obj{foo}
+        obj.*foo
+        obj->foo
+        obj<-foo
+        obj@[foo]
+        obj.[[foo]]
+    with "obj.[foo]" emerging as the preferred one.  In this initial
+    discussion, the two-argument form was universally disliked, so it
+    was to be taken out of the PEP.
+    Discussion then took a step back to whether this particular feature
+    provided enough benefit to justify new syntax.  As well as requiring
+    coders to become familiar with the new syntax, there would also be
+    the problem of backward compatibility --- code using the new syntax
+    would not run on older pythons.
+    Instead of new syntax, a new "wrapper class" was proposed, with the
+    following specification / conceptual implementation suggested by
+    Martin von Loewis:
+        class attrs:
+           def __init__(self, obj):
+             self.obj = obj
+           def __getitem__(self, name):
+             return getattr(self.obj, name)
+           def __setitem__(self, name, value):
+             return setattr(self.obj, name, value)
+           def __delitem__(self, name):
+             return delattr(self, name)
+           def __contains__(self, name):
+             return hasattr(self, name)
+    This was considered a cleaner and more elegant solution to the
+    original problem.  (Another suggestion was a mixin class providing
+    dictionary-style access to an object's attributes.)
+    The decision was made that the present PEP did not meet the burden
+    of proof for the introduction of new syntax, a view which had been
+    put forward by some from the beginning of the discussion.  The
+    wrapper class idea was left open as a possibility for a future PEP.
-    [4] http://mail.python.org/pipermail/python-ideas/2007-February/000210.html
-    [5] http://mail.python.org/pipermail/python-ideas/2007-February/000211.html
-    [6] http://mail.python.org/pipermail/python-ideas/2007-February/000212.html
+    [1] Sourceforge patch #1657573
+        http://sourceforge.net/tracker/index.php?func=detail&aid=1657573&group_id=5470&atid=305470
-    [7] http://mail.python.org/pipermail/python-ideas/2007-February/000213.html
+    [2] http://mail.python.org/pipermail/python-ideas/2007-February/000210.html
+        and following posts
-    [8] http://mail.python.org/pipermail/python-ideas/2007-February/000227.html
+    [3] http://mail.python.org/pipermail/python-dev/2007-February/070939.html
+        and following posts

More information about the Python-checkins mailing list