Waffling (was Re: single-line terinary operators considered harmful)

Thomas Wouters thomas at xs4all.net
Wed Mar 5 17:11:57 CET 2003

On Wed, Mar 05, 2003 at 02:45:53PM +0000, Stephen Horne wrote:

> On Wed, 5 Mar 2003 12:43:05 +0100, Thomas Wouters <thomas at xs4all.net>
> wrote:

> >On Wed, Mar 05, 2003 at 11:06:46AM +0000, Stephen Horne wrote:
> >> just as Guido kept ';' as an optional statement terminator.

> >';' is more of a statement separator than a terminator. From the Grammar
> >file:

> >simple_stmt: small_stmt (';' small_stmt)* [';'] NEWLINE

> Hmmm - that final [';'] looks like an optional terminator, even for
> the final statement in the line, to me ;-) Of course, I really
> wouldn't expect to see it used.

Well, you can add whitespace between the statement and the newline... does
that make whitespace an 'optional terminator' too ? :-) It might seem as a
silly semantic issue, but there is definately a difference between a ';' in
C and Perl et al, and in Python. I see the final ';' above more as a
consistency feature (which is important in Python, at least to me.) And
having an "optional terminator" is just silly, it either terminates or it
doesn't, and if it's optional it doesn't really terminate :)

> Once it's optional, the separator-or-terminator distinction really
> doesn't make much difference though. IIRC the semicolon is a separator
> rather than a terminator even in C. For instance...

>   if (condition)
>   {
>     statement;
>     /* there is an implicit null statement here */
>   }

No, sorry. In C, the semicolon is a terminator, not a separator. For


is something completely different than


(And to make things even more fun,


is not what it seems to be; this will post-inc i, not pre-inc j, because of
C's syntax rules.) If the semicolon was really just a separator, C would be
able to tell when a statement (that consists of just an expression) ended
without them. In Python, statements are terminated by a newline.

> Proper indentation is good coding style in any block structured
> language, whether it's enforced or not. Even where the compiler
> doesn't use or enforce it, anyone who has to read or maintain your
> source code is likely to bite your head off if the indentation is
> confusing or misleading. I've seen cases where this almost literally
> came true. Once or twice it was only the zits and greasy hair that
> stopped me doing it myself ;-)

I've seen worse. One project I'm involved in had a function to open a
directory and read the entries looking for all files fulfilling a requirement.
As usual, it skipped files with leading dots. However, something must have
gone wrong, because the entire function was #if 0'd out, and replaced by a
function that popen()'d a perl process to do exactly the same thing. Now
this wasn't a terribly frequent operation, but still frequent enough for me
to be scared about executing perl each time :) So I tried to figure out what
was wrong with the disabled, pure C code, and found it after a single pass
of indent. This was the code before the indent:

    if (line[0] == '.');

Isn't C luverly ? :) For those who don't know C, what the above statement
does should be obvious, as it's nearly the same as the Python. Except that
in C, an 'if' suite isn't marked by a colon and an indented block, but
either by curly braces, or by being exactly one line. so

   if (condition) { code(); }


   if (condition) code();

do the same thing. The problem with the above example was the semicolon
after the if(), which basically turned the block into:

    if line[0] == '.': pass

> Some people really seem to miss the explicit '{' and '}' (or 'begin'
> and 'end' or whatever). I've never quite understood why, but having
> seen the debate run a couple of times I have accepted that to be a
> failing of my imagination.

There are also lots of people who can't seem to like Python, or really
prefer Perl. I really can't imagine that (I write Perl for a living,
nowadays, and I really wish I wasn't) but I can accept that they don't like
Python. Python apparently can't cater to everyone (but yes, I do wonder
why :) I've heard maybe one compelling reason not to use indentation,
embedding code into other markup, but having written Perl that uses HTML
templates to generate JavaScript that generate HTML tables for inside
overlays (and in particular, debugging those) I now consider that a feature.
Other uses for blocks can be solved using '# {' and '# }', in my eyes.

> >If I ever were to design my own language, I certainly would not use block
> >delimiters unless I really really had to, and even then I'd try to find an
> >alternative.

> I'm not sure I understand what you mean by finding an alternative. An
> alternative to '{' and '}'? Or a wider alternative avoiding any
> explicit delimiting tokens, yet different to indentation?

No, an alternative to solve the problem that would otherwise be solved by
not making indentation mark blocks. E.g. issues with embedding the code into
other markup. I would rather solve that in the embedding than in the

> If you'd look for a non-delimiter solution, the only real alternative
> I can think of is a continuation-based system - like using '\' to
> continue statements over multiple lines. Which leads me to say -
> "yuck!!!". I find multiline statements generally get that way by
> containing big expressions, so I use extra brackets to avoid the '\' -
> which brings us back, in principle, to delimiters!

On the other end of the spectrum, I find that whenever I think I need a \, I
go back and look at the code, and decide another way with a shorter 'if' or
one that continues naturally (like braces) is clearer, and I end up with (to
me) nicer code. This often involves more objects and more features, without
too much extra effort. (I find I do that a lot nowadays, incremental
software development by running several cycles (including tests, of course)
before releasing the product to user-testing. :)

> Delimiters aren't really bad in principle, or else they wouldn't have
> lasted this long in so many different languages. It's just that
> indentation is usually even better - or else it wouldn't be considered
> good style in languages that already require delimiters.

Don't forget that programming languages are still in development. They are
quite new, and also have to struggle to keep in pace with hardware
development. Considerations that were true for such languages as FORTRAN or
C, such as ease and efficacy of parsing, compiler-writing and resulting
code, are no longer an issue for a language as, say, Python or Perl or even
language that share part of the domain, such as Java and C++.

And also don't forget that languages are designed by humans, and many
designers build on the features that they are familiar and comfortable with
-- even if they aren't terribly efficient. Even Python! Python really isn't
that innovative as a language, it's just very well put together, both in
design and in implementation. Just look at how strained the ternary operator
proposals all look; the idea comes from C and Perl (for many people, at
least) and so the tendency is to make the syntax look like C -- and all
other syntactic suggestions look odd. (Or is that just me ? :)

Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

More information about the Python-list mailing list