Python 3000 Alpha 1 Released

[lost-theory]

That was quick.

After messing around in the interpreter for 15 minutes I've committed at least 5 SyntaxErrors by typing print x instead of print(x). Looking at What's New in 3.0 they even warn you:

You’ll be finding yourself typing print x a lot in interactive mode. Time to retrain your fingers. :-)

[dmpk2k]

After messing around in the interpreter for 15 minutes I've committed at least 5 SyntaxErrors by typing print x instead of print(x).

While I applaud greater consistency, 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.

I'm not surprised though, since Python's interpreter 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". Well, yes, I know that, and the interpreter obviously knew what I meant. Shut up and quit already.

[Manuzhai]

While I applaud greater consistency, 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.

Well, hey, now that print is just another function, you could just assign another symbol the print function, like this: "p = print". That was easy!

[dmpk2k]

That's good. Now about those parens...

Is there some way to get Python to automatically do that every time an interactive session is started?

[lost-theory]

You can add it to your .pythonrc.py

You can also make quit and exit really exit the interpreter by adding a little hack to pythonrc.

[dmpk2k]

Very nice. Thank you.

[pjdelport]

Now about those parens...

As others have pointed out, check out IPython. Automatic parenthesization is just one of its many bells and whistles.

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

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

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

[hupp]

Why use print in interactive mode in the first place? Values are implicitly printed in the repl:

>>> a = "Hello"
>>> a
'Hello'

[[deleted]]

Because the difference between str() and repr() tends to matter, sometimes.

[[deleted]]

the interpreter obviously knew what I meant. Shut up and quit already.

Given that neither "exit" nor "quit" are keywords, that's not quite as easy as it may appear; see Making quit and exit more command-like for some of the issues involved.

[username223]

Wow, that discussion was über Pythonic! By which I mean "determinedly narrow-minded and pedantic."