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

Ben North ben at redfrontdoor.org
Tue Feb 13 00:10:34 CET 2007


Guido van Rossum wrote:
 > - There's near-universal dislike for the two-arg form, so let's drop
 > that part of the proposal.

This is a strong consensus, definitely, so we can conclude that this
point has been decided.  I will remove it from the PEP.

Guido also wrote:
 > - There's a lot of support for the basic idea, and only a few
 > naysayers, so let's keep looking for a syntax that works.

If we can take that as a decision, then the various proposals for the
syntax break down as follows.


By raw numbers, the most popular choice is

   self.(method_name) = self.metadata.(method_name)

but many of the "I like that" messages were in the context of the idea
as a whole, so can't really be counted as explicit votes for "obj.(foo)"
as such.

Next, and Guido's preferred choice, is

   self.[method_name] = self.metadata.[method_name]

(I haven't been following long enough to know whether "Guido likes it"
overrides everything else (the "D" of BDFL), or is more of a casting
vote in the event of a tie.)

With regard to the potential overlookability of the dot, Guido says:
 > I recommend that you do some experiments with the readability of the
 > .[...] notation, e.g. write a program that randomly generates x.[foo]
 > and x[foo], and see how fast you can spot the difference. I bet that
 > you won't have any trouble.

I agree --- just as it's important to have a font that makes it easy to
distinguish "I" from "l" and "1", "0" from "O", "(" from "{", etc., I
would say it's important to program using a font which makes it easy to
tell whether there's a "." in your code.  I can imagine that a
proportional font where "." might be a single pixel wouldn't help,
though.  (Gently wandering off-topic, but: do people use proportional
fonts for coding?  Doesn't it cause general awkwardness for
indentation, especially relevant for python?)

Also mentioned was

   self.{method_name} = self.metadata.{method_name}

which could not be confused either with function call or indexing but
perhaps would preclude braces from any potential future use.

Exploring other ideas, the "arrow" notation

   self->method_name = self.metadata->method_name

has support, and is clearly different, but I personally would be misled
to think, from the meaning in C, that it ought to be the left-hand
operand which is dereferenced somehow.  Guido has the same opinion, and
is "strongly -1" on this.

The "star" form has the "dereference" meaning from C, and is certainly
visually distinctive:

   self.*method_name = self.metadata.*method_name

and explicit parentheses could be put in as a syntax requirement, or by
individual coder preference, or for more complex attribute calculations:

   self.*(method_name) = self.metadata.*(method_name)
   self.*('foo_%d' % n) = self.metadata.*('foo_%d' % n)

The downside is that it could be considered "visually distinctive" to
the point of being line noise.


Could we cut down the choice to

   self.[method_name] = self.metadata.[method_name]

if the danger of overlooking the dot were deemed small enough, or

   self.*(method_name) = self.metadata.*(method_name)

if the consensus was that something more noticeable was needed?


(Or there's always the late arrival

 > > In C, "x->y" dereferences x, while in Python, "x->y" would 
dereference y.
 >
 > Then the syntax should obviously be "x<-y".
 > [insert in-Soviet-Russia-variables-dereference-you joke here]

from Benji York.)


Ben.



More information about the Python-Dev mailing list