On Sat, May 31, 2014 at 5:28 AM, Steven D'Aprano
<steve+comp.lang.pyt...@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
--
https://mail.python.org/mailman/listinfo/python-list
