[Python-Dev] New syntax for 'dynamic' attribute access (original) (raw)

Ben North ben at redfrontdoor.org
Mon Feb 12 15:40:53 CET 2007

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

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.

More information about the Python-Dev mailing list