Re: [Python-ideas] Inconsistent script/console behaviour
(moved thread to python-ideas, where it belongs. Messing with 20 years of precedent is *not* a topic for python-dev) On Thu, Dec 15, 2011 at 6:58 PM, anatoly techtonik <techtonik@gmail.com> wrote:
You can't fix this without completely changing the way the interactive console treats blank lines.
But the fix doesn't require changing the way interactive console treats blank lines at all. It only requires to finish current block when a dedented line is encountered and not throwing obviously confusing SyntaxError. At the very least it should not say it is SyntaxError, because the code is pretty valid Python code. If it appears to be invalid "Python Console code" - the error message should say that explicitly. That would be a correct user-friendly fix for this UX issue, but I'd still like the behavior to be fixed - i.e. "allow dedented lines end current block in console without SyntaxError". Right now I don't see the reasons why it is not possible.
Please speak code when replying about use cases/examples that will be broken - I didn't quite get the problem with "global scope if" statements.
There are two steps to what the interactive console does: Step 1: accept a block of code. Step 2: compile and execute it in single statement mode (in order to get the result of any expressions for display) It is the *first* step that is terminated by a blank line. That step understands almost nothing about Python syntax - just enough to figure out whether or not it should be asking for a continuation line. (IIRC, it pretty much just does bracket matching and "if I have seen a ':' character, ask for continuation lines until one of them is blank". So yes, fixing example 1 *does* require significant changes to the way the interactive interpreter works. The interactive interpreter currently operates on individual statements. For compound statements, those statements are terminated by a blank line. If you don't terminate them correctly, then it will attempt to interpret two statements as one, and hence you will get UnexpectedDedentError. To fix example 1, the interactive interpreter would have to be redesigned to use exec mode instead, so it can accept multiple statements at once. That's not impossible, but is a lot of effort to address a relatively minor inconvenience (the inability to tolerate blank lines *within* a suite significantly more annoying in my experience, but even harder to fix than example 1 would be). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, Dec 15, 2011 at 3:41 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
There are two steps to what the interactive console does:
Step 1: accept a block of code. Step 2: compile and execute it in single statement mode (in order to get the result of any expressions for display)
It is the *first* step that is terminated by a blank line. That step understands almost nothing about Python syntax - just enough to figure out whether or not it should be asking for a continuation line. (IIRC, it pretty much just does bracket matching and "if I have seen a ':' character, ask for continuation lines until one of them is blank".
Actually, in CPython at least, the first step uses a special feature of the parser that can tell whether what has been entered so far is complete or not. Try entering a subtle syntax error:
def foo(): ... x = 1 ... y x File "<stdin>", line 3 y x ^ SyntaxError: invalid syntax
It does treat an entirely blank line (with no comment or whitespace) as a dedent all the way back to zero. The problem with allowing what Anatoly asks for is that the added line could introduce another indented block instead of just a statement. Almost all languages with an interactive mode have some kind of syntactic awkwardness or differences. E.g. I recently had problems with Haskell's interactive mode, which won't let you define functions directly -- you must use 'let'; and sqlite3 reads anything until you enter a semicolon. Trying to mess with Python's approach is likely to make things worse in some other way. If you think otherwise, show us the patch. -- --Guido van Rossum (python.org/~guido)
participants (2)
-
Guido van Rossum -
Nick Coghlan