How to run script from interpreter?

[Steven D'Aprano]

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.python at 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.python at 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/