Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #72317
| 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) |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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