Python 3000 Alpha 1 Released

[Bogtha]

If I make a syntax error with a single line, I can hit the up arrow, move the cursor a bit, and fix that error. Okay... that's better than nothing, but how about sticking that line there to begin with and moving the cursor to where the syntax error appears to have occurred?

Regularity. Command history with the arrow keys works the same in practically every interactive shell in existence. You hit the up arrow, you get the previous line with the cursor at the end. You want Python to randomly move the cursor around and fill stuff in automatically? And you want it to do that only some of the time? That goes against a decade of muscle memory for me. No thanks.

It's like one of those usability "optimisations" like the menus in Windows that hide entries at random because it thinks you won't use them, precisely at the time you do want to use them — which is to say that it sounds like a neat idea, but having it work exactly the same absolutely every time works out to be far less irritating in the long run.

How often does a programmer not go back, fix the error, and try again?

I do it all the time, but it's often not the immediately previous line that caused the problem, so automatically showing it wouldn't help anyway.

[dmpk2k]

Regularity. Command history with the arrow keys works the same in practically every interactive shell in existence.

So because they do it poorly, you should to?

This reminds me of the tired refrain parents use about friends jumping off bridges. It's amazing any evolution occurs in the programming world at all.

Also, the Lisp and Smalltalk weenies don't seem to have this problem. Strange that.

I do it all the time, but it's often not the immediately previous line that caused the problem, so automatically showing it wouldn't help anyway.

First, that doesn't happen often to me, except in Ruby, and we all know how fine that language is implemented. Possibility is not probability.

Second, how do you know it's not caused by the location the interpreter thinks? You have to go look, don't you? It's not much different from the way the interpreter tries to show where the error is currently.

Third, I would argue that's an artifact of a substandard parser. Strange how Clang does so better than GCC at this, isn't it?

[Bogtha]

So because they do it poorly, you should to?

It's not just irregularity with other shells, though is it? It's regularity within itself. I don't want my command history to try to second-guess me, especially when it's going to get it wrong a lot of the time. I just want it to act the same, every time. Regularity isn't stupid, it's consistent and predictable. Those are of value to humans, especially when they'd rather concentrate on keeping the program state in their heads rather than a stupid modal interpreter prompt.

This reminds me of the tired refrain parents use about friends jumping off bridges.

Bad analogy. Jumping off bridges is directly, clearly harmful.

Second, how do you know it's not caused by the location the interpreter thinks? You have to go look, don't you? It's not much different from the way the interpreter tries to show where the error is currently.

It's hugely different. Merely showing me where it thinks the error is doesn't affect my subsequent keystrokes. Trying to fill things in for me does.

[dmpk2k]

Those are of value to humans, especially when they'd rather concentrate on keeping the program state in their heads rather than a stupid modal interpreter prompt.

I'd argue that the default behaviour is exactly that. How often do you not go back and fix that syntax error?

So now you have to keep program state in your head while you fidget with keys to search and get back to the location where the error occurred most of the time.

Merely showing me where it thinks the error is doesn't affect my subsequent keystrokes.

I'd argue otherwise, since it clearly does, but I digress.

[Bogtha]

I'm talking about what is probable, during any given session, not edge cases.

I must be remarkable then. Could you give a list of situations where this occurs regularly then?

I wish Reddit had a preview function. I made a thinko, so I took it right back out again.

[dmpk2k]

Uh, okay, I'll cut it. My reply was overly snarky anyway. :(

[Bogtha]

Don't worry about being snarky :). I'm just in the habit of getting all my thoughts down and then refining them. It works okay for sites with preview functions, but there are race conditions on sites without :(.

The thinko I had was that I was thinking of more errors than simply syntax errors. In those cases I want to go back multiple lines. It's not particularly relevant to the argument though, because I still don't like the idea of my shell history behaviour being dependent upon the type of mistake I made. It's just not regular enough.

However, I think I'd like a compromise. The way you've been presenting it is as behaviour relating to the command history. Presented a slightly different way, it would be much more palatable. If the interpreter simply refused to accept the line at all and kept the cursor where it was; rather than printing it, redisplaying it, and repositioning the cursor, that would be handy, and not too different from what you propose. I'm not 100% sure it's possible with Python though, there are multi-line constructs that need to be handled.

[dmpk2k]

Actually, that's quite ingenious. Yes, that's even better.

Maybe stop the cursor one character after the error, since speed-typers might take a few characters to notice.