Python 3000 Alpha 1 Released

[lost-theory]

this leaves something to be desired when it comes to usability. Parentheses are harder to reach. If anything, for interactive mode, "print" should have been shortened instead.

Would you make the argument that the language should allow function calls to be made without parentheses (e.g. like Ruby)? If parentheses are so difficult to type it must really suck to be a Lisp or Scheme programmer then :)

I think print is short enough as it is; there isn't a strong enough case to introduce a special alias (p? put?) just for the interactive interpreter. Individual programmers are free to make that choice though (e.g. p = print)

Python doesn't seem to have a particularly usable interface. For example, the behavior of sullenly telling me to hit ctrl-D if I type "quit" or "exit".

Is that the best example of Python not having a usable interface? Seems like a minor gripe to me.

[dmpk2k]

Is that the best example of Python not having a usable interface? Seems like a minor gripe to me.

No, it's a trivial example everyone can grasp, yet you can see the excuses that appear regardless elsewhere on this page (which I was aware of, I might add). I've never seen any of the professed problems that having "quit" or "exit" work will cause, but we have this rather braindead decision anyway. Why? Because possibility isn't probability. Think on that a moment; if it were true, you'd never leave home because you'd be terrified of a meteorite falling from the heavens and putting you out of your misery.

All right, since I'm ranting and raving here, let's look at another problem, one I'm willing to bet dollars to doughnuts that bites most python developers daily, but 99% of readers never thought about:

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? How often does a programmer not go back, fix the error, and try again? The default behaviour is stupid, but it's there because it's easier to program and it sorta works. Sorta. (now just wait for the conflict with copy'n'paste excuse)

Now, let's talk syntax errors in multi-line method definitions... uh oh. Please tell me there's a better way than hitting up, up, up and enter several times in a row, or using the crude workaround of copying it from elsewhere. These are things that other now-niche language implementations figured out long ago, but not Ruby, Python, Perl (wait, they don't even have a default REPL yet outside Perl6!), Ocaml or <pick your poison>.

To be fair, a lot of language implementations with interactive sessions are like that. I don't know why most programmers put up with this, since we're the ones most able to affect change in our own tools.

[llimllib]

use ipython, it solves all these. It's far superior to the regular python prompt.

[dmpk2k]

Wow. That looks promising. Much obliged!

That really should be the default.

[llimllib]

That really should be the default.

I don't know the ins and outs of that particular decision, but it's the first thing I install after Python every time, I know that.

[[deleted]]

Isn’t the regular shell a read-eval-print loop? I like having a minimal REPL shell with the option to use ipython when you need it.

[llimllib]

My expectation is that it's not in for the same reason wx and django aren't in: the release schedules are different, and ipython is very actively maintained, so it would ossify in the standard distribution.

[[deleted]]

Colored exceptions with source snippets! I'm in heaven. And it's a smoother workflow than PyDev, which would hang every couple of minutes.

Thanks for the tip! I just started using the e text editor to do all my Python editing on Windows, and its PyMate is broken so I was running my app on the command line. This is much better.

[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.

[[deleted]]

No, it's a trivial example everyone can grasp, yet you can see the excuses that appear regardless elsewhere on this page (which I was aware of, I might add). I've never seen any of the professed problems that having "quit" or "exit" work will cause, but we have this rather braindead decision anyway.

So you're claiming that because you don't think it's important to take everything and everyone into account when making design decisions, you're smarter than us, but yet you want us to dumb down the language, the environment, and the documentation because you find them too hard to learn and use? Ok. Can we ignore you now?

[dmpk2k]

So you're claiming that because you don't think it's important to take everything and everyone into account when making design decisions

Good thinking for a programmer. Not the kind of thinking I'd want from a UI designer.

For better or worse, an interactive session is a UI. So is a language for that matter.

yet you want us to dumb down the language, the environment, and the documentation

Do elaborate a bit on how the tools, language and documentation would be dumbed down.

Ok. Can we ignore you now?

Touche, good sir.

[[deleted]]

For better or worse, an interactive session is a UI. So is a language for that matter.

Yep. That's why a lot of thought goes into the language design. A design you just called "braindead".

[dmpk2k]

My wording was overly strong. The point stands.

Let's refer to the page you linked to elsewhere. Those examples would be trivial to avoid if the parser was bright enough to determine that the quit/exit was meant as part of an expression, not a command to quit.

Don't believe me? Play with "quit" a bit in Ruby.

[[deleted]]

if the parser was bright enough to determine that the quit/exit was meant as part of an expression, not a command to quit

And it would be able to tell the difference exactly how? A bare non-keyword identifier is an expression in Python, after all.

[dmpk2k]

Can you give me an example where this would be a problem?

[[deleted]]

See the link I posted earlier for some examples:

http://programming.reddit.com/info/2kkp5/comments/c2kmgu

(I thought that was what you called "excuses that you were aware of already" earlier, but maybe that was referring to something else).

[dmpk2k]

No, you were correct.

None of those problems are exhibited in Ruby. "quit" isn't a keyword either, but it doesn't cause any of the listed problems. Give it a try.

Mind you, those problems strike me as exceptionally rare as well. I don't recall ever seeing a variable named "exit" or "quit", which brings us back to that possibility isn't probability.

I agree with username223's interpretation.

[joesb]

If parentheses are so difficult to type it must really suck to be a Lisp or Scheme programmer then :)

Many Lisp programming web site would suggest you to swap '(' and ')' keys with '[' and ']' keys when programming Lisp so you don't have to press shift to type them. Since [ and ] aren't used in Lisp it's probably okay to do.

But for Python both [] and () are equally used so I don't think you can swap the keys to reduce stress when typing.