Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #72317

Re: How to run script from interpreter?

References (9 earlier) <5388233e$0$29978$c3e8da3$5496439d@news.astraweb.com> <mailman.10477.1401434346.18130.python-list@python.org> <53886b1e$0$29978$c3e8da3$5496439d@news.astraweb.com> <mailman.10483.1401450424.18130.python-list@python.org> <5388dbd9$0$29978$c3e8da3$5496439d@news.astraweb.com>
Date 2014-05-31 05:47 +1000
Subject Re: How to run script from interpreter?
From Chris Angelico <rosuav@gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.10494.1401479273.18130.python-list@python.org> (permalink)

Show all headers | View raw


On Sat, May 31, 2014 at 5:28 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Before you ask, there is no absolutely hard and fast line between "shell
> feature" and "Python code", but the more closely your shell features
> resemble Python code, the harder it will be for users (power or not) to
> keep them separate in their head and the more likely they will be
> confused. E.g. suppose my shell decided to allow lines like
>
> var = len []
>
> to define the variable var and set it to 0. I'd argue that crosses the
> line from "useful convenience feature for power-users" to "dangerously
> confusing misfeature" because it looks too much like Python code. (I'm
> already dubious about len [] on its own.) A better interface is to have a
> clear separation between shell commands and Python, and IPython commonly
> usually uses prefix sigils such as ; % and ! for that.

I think this is the nub of the issue. You believe that anything that's
syntactically legal in a script MUST (a) be syntactically legal, and
(b) have the same semantics (modulo the printing part mentioned below)
in the interactive interpreter. I'm a little less strict, and would be
okay with some things that make little sense being disallowed. There
are already a few such things (you mention the blank line issue), and
the question is more whether they're recommended or not, than whether
they're allowed or not. (Python 3's super() is a piece of magic, and
it's better that it be magical, but it isn't a precedent to be
followed.) I can accept that the desirable line is further over than I
was putting it; practicality is only so-much of an argument.

> You raise the issue of the vanilla Python shell printing the result of
> expressions. That would be the P in REPL, yes? :-) It would be a funny
> REPL that *didn't* print evaluated expressions.

Yes of course, but there's a difference between these:

>>> 1 + 2
3
>>> while True:
    input("Echo? ")
    if _=="Echo!": break

The first one is using the REPL exactly the way everyone would expect
it to be used. A single expression is entered, and it is printed.
Failing to do that is, indeed, failing on the P of REPL. (That said, a
Read-Eval Loop, sans Print, is still of value. I used one for over a
decade with REXX, manually prefixing things with "say" when I wanted
them printed, err I mean said.) But the second one is looking a lot
more like a script, and if you're writing code like that, you really
should think about assigning the input to a variable and explicitly
printing it, not fiddling with automatic display and the _ capture.

A "top-level expression", if you like, should definitely be printed.
An inner expression isn't so fundamental. Since Python has been
written to print them, we can make use of it; but a REPL that didn't
print inner expressions is still a useful tool. Printing inner
expressions is sliding toward the line of dangerously confusing
misfeatures that you mentioned; you could compose a massively long
function, and deep inside it, call something and have its return value
printed - and then paste that into a script and find that it's not
printing any more. Or, possibly worse, come to python-list with the
question "How do I fix this?", not even knowing what the problem is,
and having us all assume it's a script.

It's a grey area. What's a convenient and useful feature, and what's a
problem? Is supporting "print 1+2" in Python 3 on one side or the
other of that line?

ChrisA

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: How to run script from interpreter? onlyvinish@gmail.com - 2014-05-28 00:44 -0700
  Re: How to run script from interpreter? Terry Reedy <tjreedy@udel.edu> - 2014-05-28 11:32 -0400
  Re: How to run script from interpreter? Mark H Harris <harrismh777@gmail.com> - 2014-05-28 11:39 -0500
    Re: How to run script from interpreter? Steven D'Aprano <steve@pearwood.info> - 2014-05-29 03:22 +0000
      Re: How to run script from interpreter? Mark H Harris <harrismh777@gmail.com> - 2014-05-29 15:26 -0500
        Re: How to run script from interpreter? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-30 00:33 +0000
          Re: How to run script from interpreter? Chris Angelico <rosuav@gmail.com> - 2014-05-30 10:46 +1000
            Re: How to run script from interpreter? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-30 01:49 +0000
              Re: How to run script from interpreter? Chris Angelico <rosuav@gmail.com> - 2014-05-30 12:04 +1000
                Re: How to run script from interpreter? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-30 06:20 +0000
                Re: How to run script from interpreter? Chris Angelico <rosuav@gmail.com> - 2014-05-30 17:19 +1000
                Re: How to run script from interpreter? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-30 11:27 +0000
                Re: How to run script from interpreter? Chris Angelico <rosuav@gmail.com> - 2014-05-30 21:46 +1000
                Re: How to run script from interpreter? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-30 19:28 +0000
                Re: How to run script from interpreter? Chris Angelico <rosuav@gmail.com> - 2014-05-31 05:47 +1000
                Re: How to run script from interpreter? Terry Reedy <tjreedy@udel.edu> - 2014-05-30 11:24 -0400

csiph-web