FWIW, I'm strongly -1 on the "->" notation. As a C programmer it's got
too many neurons committed to it.
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.
--Guido
On 2/12/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> 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/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
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
