On Fri, 30 May 2014 12:04:27 +1000, Chris Angelico wrote:
> On Fri, May 30, 2014 at 11:49 AM, Steven D'Aprano
> <steve+comp.lang.pyt...@pearwood.info> wrote:
>> 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;
Heavens no. If it's legal in a script when running non-interactively, it
should be legal when running interactively.
I give a grudging exception to things like the REPL ending a function
definition at the first empty line, even though it breaks copy-and-paste
of working code:
py> def example():
... do_this()
...
py> do_that()
File "<stdin>", line 1
do_that()
^
IndentationError: unexpected indent
That's a *serious* PITA when copying (say) classes into the interactive
interpreter, because you have to delete all the blank lines (or stick
comments # in them) before pasting. But I can't see any practical
alternative.
> for instance, it's perfectly valid to write
> this:
>
>>>> x = (1
> .
> imag)
Absolutely it is valid Python code, so your REPL better accept it as
valid Python code.
> 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've never come across that. I'm very glad I haven't. Who came up with
that broken interface?
> 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.
Damn straight it ought to. If I proposed making:
x = (1
+
y)
do something other than set x to 1+y, I would completely deserve to be
dragged out into the street and beaten with halibuts. Replace the + with
a dot, and there is no difference at all. If you want to kill the current
buffer, just hit Ctrl-C like you're meant to.
> 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.
I don't see any connection between the two.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
