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

[Ben North]

Thanks for the comments so far on this.  First, on the general idea:

Neil Toronto:
> I like it.
> [...]
> >   obj.(attr_name) += 1
> Even nicer; much, much better than the current spelling.

Brett Cannon:
> +0 on the one-item version.

Anthony Baxter:
> -1 from me.

Collin Winter:
> I like the general idea [...] I'm +0 on the idea

Jack Jansen:
> I like the functionality,

Raymond Hettinger:
> I also like the functionality.

Generally gently positive, with the exception of Anthony Baxter's
"-1", which I understand to be motivated by concerns about newcomers to
the syntax:

> Someone coming across this syntax for the first time will not have any
> hints as to what it means - and worse, it looks like a syntax error to
> me.

This was echoed by Collin Winter:

> Also, like Anthony Baxter said, someone coming across this for the
> first time will think it's a syntax error, allusions to MATLAB and
> assembly indirection syntax not withstanding. [...] -1 on the means.

I think the argument "someone who hasn't come across it before won't
know what it is" could be applied to any new syntax, for instance the
new "with" statement, or going further back in time, the introduction of
Booleans, semantics of "__slots__", the "extended print" syntax, the
"list comprehension" syntax, the "augmented assignment" syntax, etc.
Some of these were perhaps more transparent than others, but for
instance "with" needs a bit of study to fully understand what's going
on.  I would argue that the newness itself is not sufficient reason to
reject this.

Also, I think it's a good thing that it looks like a syntax error --- it
*is* currently a syntax error.  A newcomer will be alerted to the fact
that something new is going on and will know to go and find out about
it.  I am happy to write a paragraph for the "what's new" release notes,
and/or new section(s) for the documentation describing the new syntax.


On the two-argument form, feeling was generally pretty negative, with a
few "-1"s thrown in.  I propose to cut this piece out of the PEP,
leaving just the one-argument form.  If a default value is required, the
coder can still use the three-argument form of "getattr".  To be clear
(and I'll put this in the PEP), I'm *not* suggesting that python loses
"getattr", "setattr", or "delattr".


On the syntax:

Brett Cannon:
> It just makes it look like too much of a function call at that point
> to me

Collin Winter:
> the syntax looks like dirt on my monitor.  The period is too easy to
> lose visually and without it, there's nothing to distinguish this from
> a function call.

Jack Jansen:
> I don't like the syntax, to me it looks too much like a method call.

(Some of the initial comments in python-ideas were along these lines
too.)  My personal opinion is that "obj.(foo)" is distinct enough from
"obj(foo)" to not cause confusion, but perhaps in a proportional font it
is less clear.

Some people made concrete suggestions as to what syntax could be used
instead:

Jack Jansen:
> To me self.[method_name] = self.metadata.[method_name] looks better:
> what we're doing here is more like dictionary lookup than calling
> functions.

In the same way, though, would this be viewed as too similar to normal
dictionary/list indexing?

Raymond Hettinger:
> Rather than munge existing syntaxes, an altogether new one would be
> more clear:
>
>    self->name = self.metadata->name

One thing which comes to mind about this one is that, for C/C++
programmers, the difference between

   obj.member            and             obj->member

is the interpretation of the thing on the *left* of the dot or arrow,
whereas the PEP is discussing a new interpretation of the thing on the
*right* of the dot.

One idea mentioned in the PEP is to bring {}s into service here, but I
think the dot should be kept to keep it looking like an attribute
access.  What would the reaction be to

   obj.{member}

instead?  Braces are already used to construct dictionaries, so this has
some of the right connotations.  It could not be confused with either a
function call or a dictionary lookup/list indexing.

(Nobody had any comments on the potential 1% performance hit --- is this
because it's too early to worry about implementation details?)

Thanks,

Ben.