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

Georg Brandl g.brandl at gmx.net
Mon Feb 12 16:19:57 CET 2007

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

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

More information about the Python-Dev mailing list