Apologies: I overlooked a couple of replies in my summary earlier. Tim
Delaney and Terry Reedy both responded in positive terms to the
one-argument form and its syntax, and in negative terms to the
two-argument form.
Also, I missed the fact that Neil Toronto had made the same point as me
when he said:
> I'm not sure the "looks like a syntax error" argument holds much weight,
> because any new syntax is likely to be a syntax error until the syntax
> is changed. :)
he also suggested:
> obj.*str_expression
but I'm a bit uneasy about this, although the similarity with C's
dereferencing is in its favour. Also, '*' in python is already used for
"and the rest" arguments in function calls.
Anthony Baxter cooled off a bit on the idea too:
> after thinking about it a bit, I'm still not convinced this is
> something that needs shorthand syntax
Maybe not, but for the cases where you do want to do dynamic attribute
access, I think there is a win in readability from nested getattr and/or
setattr calls.
Georg Brandl:
> -1 here too. I fear that this gets too indistinguishable from normal
> calling syntax,
I think, from the context, that this is "-1" on the syntax rather than
the idea as a whole, but I could have misread Georg's message. Possibly
a "-0" on the idea?
Greg Ewing:
> In my experience, the amount of code which truly needs
> to use getattr is extremely small.
Another "-0"?
Gustavo Carneiro:
> -1 from me. It does not solve a common problem, therefore it does not
> deserve a special syntax.
It's not *that* uncommon, judging by the c.600 uses in the existing
library code.
> Moreover, the existing syntax may be longer
> to type but is far more readable.
I disagree, although I can see that there might be a small time during
which one is getting familiar with the new syntax. Others have voiced
the opinion that it's a readability win.
Tim Delaney asked in particular:
> Have you checked if [the existing uses of getattr, where "getattr" in
> that scope is a function argument with default value the built-in
> "getattr"] are intended to bring the "getattr" name into local scope
> for fast lookup, or to force a binding to the builtin "gettattr" at
> compile time (two common (ab)uses of default arguments)? If they are,
> they would be better served by the new syntax.
They're all in Lib/codecs.py, and are of the form:
class StreamRecoder:
def __getattr__(self, name,
getattr=getattr):
""" Inherit all other methods from the underlying stream.
"""
return getattr(self.stream, name)
Without digging deeper into that code I'm afraid I can't say precisely
what is going on.
Ben.
_______________________________________________
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
