On Fri, May 30, 2014 at 11:49 AM, Steven D'Aprano
> On Fri, 30 May 2014 10:46:34 +1000, Chris Angelico wrote:
>> On Fri, May 30, 2014 at 10:33 AM, Steven D'Aprano
>> <steve+comp.lang.pyt...@pearwood.info> wrote:
>>> (By the way, ; won't work for a Python shell, because ;spam already is
>>> valid Python syntax: it's an empty statement followed by the statement
>>> spam, separated by a semicolon.)
>> That's not really a problem, though. It's not going to stop you from
>> doing something actually *useful*, and the fact that the semicolon could
>> be syntactically valid isn't going to come into it, because the REPL
>> would swallow it anyway.
> The point is that *syntactically valid* Python statements should not
> behave differently when running inside the shell or not. I thought
> that ;statement was syntactically valid -- but I was wrong. The vanilla
> CPython interactive interpreter gives a syntax error, as do IronPython
> and Jython.
Huh. I responded to your post on the unchecked assumption that ";spam"
was syntactically valid. I'm still of the opinion that technically
valid (but not useful) constructs are allowed to be swallowed by an
interactive interpreter; for instance, it's perfectly valid to write
>>> x = (1
But quite a few interpreters (though not Python) take a dot on its own
line to mean "flush the buffer, cancel my current command". I couldn't
find a way to do this in Python, but if someone proposed adding it,
the fact that the above is syntactically legal shouldn't be a proposal
blocker. It's on par with creating a file with a name beginning with a
hyphen, and then fiddling around with various commands as you try to
manipulate it (tip: "rm ./-r" works); programs will happily interpret
"-r" as an option rather than a file name, without being concerned
that it's technically legal.