Home Original page

Thoughts on PEP315

Stephen Horne $$$$$$$$$$$$$$$$$ at $$$$$$$$$$$$$$$$$$$$.co.uk
Wed Sep 24 13:24:44 EDT 2003 
On Wed, 24 Sep 2003 17:50:11 +0100, Tim Rowe
<tim at remove_if_not_spam.digitig.co.uk> wrote:

>On Wed, 24 Sep 2003 01:02:47 +0100, Stephen Horne
><$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote:
>
>>This would be a nightmare for the parser - until it finds the colon or
>>end-of-line (or semicolon perhaps) it simply wouldn't know which case
>>it was dealing with.
>>
>>But if this is bad for the parser, just think what it would do to
>>users! - forgetting a trailing semicolon shouldn't result in a
>>statement which is legal yet with a significantly different meaning.
>
>That's why I don't like it in Perl and Ruby -- I can tell it's hard
>for the parser because so few syntax highlighters get it right!
>
>Maybe I'm getting twitchy about nothing -- after all, indentation
>being significant brough back unhappy memories of FORTRAN, but Python
>makes it work...

That was basically a fluked typo - I meant the missing the trailing
colon at the end of the 'break if ...' line, but of couse a semicolon
added/lost semicolon in the wrong place can be just as bad.

I don't think this would hurt Python the same way, though, as 'if'
cannot follow after a statement on the same line for (presumably to
ensure that the indentation makes sense)...

>>> break ; if 1 :
  File "<stdin>", line 1
    break ; if 1 :
             ^
SyntaxError: invalid syntax


So a 'break if ... :' cannot accidentally metamorphose into a 'break;
if ... :'.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
More information about the Python-list mailing list