> > It only takes about five minutes to try out a given syntax proposal
on
> > all the fragments listed below. That short exercise provides an
> > excellent insight into the look and feel of each proposal in real
world
> > code.
>
> I did this for my favorite proposal, and ended up with the list shown
> further down below.
>
> I think they all looks great!
They mostly look great to me too :-)
The exceptions are the ones in pydoc which have an odd feel to them and,
to my eyes, don't parse well. I can't put my finger on the issue -- it
could be that any ternary operator syntax breaks down when used in
series with other operators or when there are complex sub-expressions.
> pydoc.py: return re.sub('^ *\n', '', rstrip(result)) if result
else ''
> pydoc.py: anchor = (cl.__name__ if cl else '') + '-' + name
> pydoc.py: lhs = '<strong>%s</strong> = ' % name if name else
''
> pydoc.py: contents = [doc + '\n'] if doc else []
> pydoc.py: line = (name + ' = ' if name else '') + repr
> pydoc.py: line = (self.bold(name) + ' = ' if name else '') +
repr
> pydoc.py: host = '127.0.0.1' if (sys.platform == 'mac')
else 'localhost'
> pydoc.py: font = ('helvetica', 8 if sys.platform ==
'win32' else 10)
There is one that looks like it could be completely mis-interpreted:
(name + ' = ' if name else '') # as written above
((name + ' = ') if name else '') # one mental interpretation
(name + (' = ' if name else '')) # an incorrect interpretation
The grouping issue doesn't arise for syntaxes that start with a keyword:
(if name then name + ' = ' else '')
but even those suffer from unclear precedence when used with binary
operations on the right: (if cond then a else b + c).
Raymond
_______________________________________________
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
