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

Brett Cannon brett at python.org
Mon Feb 12 23:04:03 CET 2007

On 2/12/07, Raymond Hettinger <python at rcn.com> wrote:

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

[Ben North] > 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. Try not to get hung-up on meanings from other languages. Any simple syntax will have associations in other languages.

An example of where Python has been willing in the past to hijack syntax and give it a tweaked meaning is decorators compared to Java annotations.

It is more important that we don't create a syntax which already has strong associations in Python (i.e. curly braces, dots, and square brackets). Those syntaxes would make the language harder to mentally parse.

I think this is a nice argument against using square brackets as well. Currently square brackets are used for getting an item from a container (getitem) or generating one (list comprehensions). While using the .[] syntax does connect with the "container" idea if you want to treat an object as a container and its attributes as its items, I don't think the connection is that strong.

Guido said he would be much more willing to look twice at a use of brackets for a dot, but that seems to require mental backtracking to me. If I am skimming some source and I see square brackets, right now I know that either something has defined getitem and is probably a dict or list, or it is a listcomp if it contains 'for'. But with this I would now have to stop and look for that dot which could be lost in the noise.

I think people are calling the syntax "dirt" because you have two pieces of syntax ('.' and '[') that are a single character. And on top of that they are extremely thin (which sucks for non-monospaced fonts). We don't have issues with dots these days since there is usually several characters of information specifying the meaning of what the dot is modified by the dot. But in this case there is very little visual queue for that.

I would like to give the -> syntax a chance as is it simple and it is provides a nice visual distinction between closely related concepts:

a.name -- getattr(a, 'name') a->name -- getattr(a, name)

Yeah, I am definitely liking this one more. It's making the .[name] or .(name) look more like "dirt on Tim's monitor" to me.

-Brett

More information about the Python-Dev mailing list