[Python-Dev] New syntax for 'dynamic' attribute access

[Steve Holden]

Ben North wrote:
> Hi,
> 
> A few days ago I posted to python-ideas with a suggestion for some new
> Python syntax, which would allow easier access to object attributes
> where the attribute name is known only at run-time.  For example:
> 
>    setattr(self, method_name, getattr(self.metadata, method_name))
> 
> from Lib/distutils/dist.py could be rewritten
> 
>    self.(method_name) = self.metadata.(method_name)
> 
> The new syntax would also be usable in augmented assignments, as in
> 
>    obj.(attr_name) += 1
> 
> There was some discussion on python-ideas, which I've linked to in the
> draft PEP below.  In particular, Guido van Rossum wrote:
> 
>  > 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.
> 
I don't like this. Just because an enhancement is syntactically 
permissible doesn't mean it's a good idea. This seems to me to take 
Python further away from the "Computer Programming for Everyone" arena 
and closer to the "Systems Programming for Clever Individuals" camp.

> so here I am.  Does anybody have any opinions/suggestions, particularly
> on the "open questions" referred to in the draft PEP?  To summarise
> these open questions:
> 
> * The draft currently allows a two-argument form, to supply a default
>   value if the object has no attribute of that name.  This mimics the
>   behaviour of the three-argument form of getattr, but looks a bit wrong:
> 
>      s = obj.(attr_name, 'default string')
> 
>   I agree that it looks odd, but perhaps the extra expressive power
>   gained might be worth the oddness.
> 
It looks extremely odd. Since the opening parenthesis takes us into new 
syntactic territory the unimaginative use of the (already heavily 
overloaded) comma would sound the idea's death-knell. If we *have* to 
have this (and I agree with Greg that many uses cases for dynamic 
attribute access are invalid) then why not

     s = obj.(attr_name: 'default-string')

I presume that the default value would in fact be an arbitrary expression?

> * The draft implementation (a sourceforge patch, linked to in the draft
>   PEP) may have a general performance penalty of around 1%, although my
>   initial measurements were quite noisy.  Josiah Carlson thought this
>   would not be too substantial, but he did suggest a couple of other
>   implementation routes which could be explored.  The general
>   performance hit is offset by a speed gain of around 40% for attribute
>   access using the new syntax over getattr etc.  Is 1% "too much" for
>   this feature?
> 
Yes. I believe it would decrease the sum total of Python's efficiency 
for a very marginal return in performance on a very marginal feature. It 
threatens to reduce Python's readability substantially, and readability 
is more important than efficiency.

"Expressive power" is all very well as long as the expressiveness is 
comprehensible. This proposal makes the left parenthesis carry a larger 
burden than the introduction of generator expressions did, and it makes 
Python a more difficult language to understand.

[provisional PEP snipped]

If it's added in 2.6 I propose it should be deprecated in 2.7 and 
removed from 3.0 ...

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb     http://del.icio.us/steve.holden
Blog of Note:          http://holdenweb.blogspot.com
See you at PyCon?         http://us.pycon.org/TX2007