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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
