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

[Ben North]

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.