On 2/12/07, Raymond Hettinger <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
