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

[Georg Brandl]

Ben North schrieb:
> 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. :)

IMO there's a difference between e.g. "with" and this new syntax. Looking
at code that uses the "with" statement, one cannot think other than "ah,
a new keyword, let's look what it means".

Here, when someone comes across "obj.(name)" the situation is different. You
also have to take into account that not all programmers know the language to
the fullest extent, so it won't only be newbies who'll be confused and probably
say "hey, that doesn't look right to me".

> 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.

Additionally, if you want to use a more complicated expression, you'll still
have to put parentheses there.

> 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.

As said in the "grit" argument, not necessarily. It's more easily overlooked
that "getattr".

> 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?

A +0 on the idea, but as I wrote in that post, I doubt an ideal and Pythonic
syntax can be found here.

> 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.

Since that is a special method and ought to have the signature
__getattr__(self, name), I think it's safe to assume that that's meant
as an optimization.

Georg