The Evolution of Python 3 215
chromatic writes to tell us that O'Reilly has an interview with Guido van Rossum on the evolutionary process that gave us Python 3.0 and what is in store for the future. "I'd like to reiterate that at this point, it's a very personal choice to decide whether to use 3.0 or 2.6. You don't run the risk of being left behind by taking a conservative stance at this point. 2.6 will be just as well supported by the same group of core Python developers as 3.0. At the same time, we're also not sort of deemphasizing the importance and quality of 3.0. So if you are not held back by external requirements like dependencies on packages or third party software that hasn't been ported to 3.0 yet or working in an environment where everyone else is using another version. If you're learning Python for the first time, 3.0 is a great way to learn the language. There's a couple of things that trip over beginners have been removed."
Re:Evolution? (Score:1, Insightful)
Can't evolution be controlled? I guess that is the same basic idea as in intelligent design, but it can be called evolution even though somebody steers where it's heading.
Re:In all seriousness (Score:2, Insightful)
Re:In all seriousness (Score:2, Insightful)
I thought the same as you once, but I changed my mind. Now the braces just plainly, insanely annoy me.
Moreover, you cannot imagine how much time is wasted in typing something that has absolutely no meaning: you have to indent anyway. Braces are just a waste of your time.
Oh good. (Score:5, Insightful)
So whitespace block delineation is finally out, in favor of braces? :P
Re:In all seriousness (Score:3, Insightful)
On the other hand, I've spent at least a full work week of my life fixing problems due to whitespace. Guido made a major fuck up there- by removing braces but not strictly defining whitespace, he's created a language where it's possible to have two identical looking pieces of code do very different things. If he had said that it must be indented by exactly 1 tab or exactly 4 spaces or whatever other measure and everything else would throw a syntax error, it would have been fine. As it is I'd say about 15-20% of the time I spent doing Python was spent fixing these kinds of bugs.
Re:Oh good. (Score:5, Insightful)
I'll preface this by saying that I program primarily in brace-based languages.
Braces suck in the worst possible way as a method of delineation. Let me give an example:
That's clearly the suck, so we break it out like:
...at which point we realize that the braces are basically useless, since the code is unreadable without the whitespace. Python just forces you to use a readable formatting, and it's not all that hard to get used to.
Re:In all seriousness (Score:3, Insightful)
I think it's ridiculous that people's biggest complaint about Python is that it's whitespace sensitive. Any frustrations with it are easily solved by using the proper tools.
Learn a text editor, and this isn't an issue. In emacs, C-c C-q will properly tabify the function you're in, and tabs should behave mostly sane thereafter.
Re:Oh good. (Score:5, Insightful)
at which point we realize that the braces are basically useless, since the code is unreadable without the whitespace.
No, it means the code is hard to read, but it still works. You can reformat that block, or you can change the spaces (tabs, number of spaces), and it will still work. In Python, it may look okay, and be readable, but it won't work.
I guess it is a matter of priorities.
BTW, I like Python (and have almost given up on Perl 6), but the white space thing drives me crazy.
Re:Oh good. (Score:5, Insightful)
The whitespace issue is a red-herring: most people get used to it quickly and it's not as strict as it sounds (you can mix-and-match tabs and spaces, as long as you are consistent for each *block*; not even an entire .py file). There's two real-world problems with it: copy-and-paste and generating Python code. Both are much less common than looking at badly-formatted code that it takes a bit to mentally parse which brace-delineated languages have.
Re:In all seriousness (Score:3, Insightful)
I would be interested to see an example of Python code where a change to whitespace causes two identical-looking pieces of code to do two different things.
The only issues that *ever* come up in such a scenario is a SyntaxError, and pretty much the only reason they ever happen en masse is due to indiscriminate copy-and-paste coding.
Syntax errors can barely even be called bugs, and in any significant project the amount of time you're going to spend dealing with them is easily dwarfed by the *real* bugs that are a natural part of the development process.
If developers are spending a truly inordinate amount of time on whitespace issues, it can only be due to lack of discretion and attention to detail, which I would be willing to wager is increasing the number of "real" bugs emerging as well.
Re:In all seriousness (Score:5, Insightful)
I've edited Python in vi, Notepad, SciTE, Geany, and other editors without any problem. Never used emacs though. If whitespace is causing bugs in your team's code you need to (a) introduce process or (b) lose some dead weight from your team. For (a) you can standardise on editor and whether to use tabs or spaces, or you can get the coders to end a whitespace block with a comment, eg # endif. I've only been using Python a couple of years but my experience so far suggests the problem is with you and not the language.
Phillip.
Re:In all seriousness (Score:5, Insightful)
If he had said that it must be indented by exactly 1 tab or exactly 4 spaces or whatever other measure and everything else would throw a syntax error, it would have been fine. As it is I'd say about 15-20% of the time I spent doing Python was spent fixing these kinds of bugs.
I have to assume that most of your time doing python has been spent copy/pasting code off the web. I've been coding python nearly daily for a couple years now. I've rarely made indentation errors, none in the last few months, and only once have I ever had an indentation error that took more than 10 seconds to debug. The thing is, most indentation errors are so visibly clear that it's really quite hard to make them.
If you're actually having problems with multiple spaces looking like tabs, you can use the -t option to make it throw an error if you use a mixture of tabs and spaces, but it really shouldn't be that hard.
Re:Probably not an issue for beginners? (Score:1, Insightful)
That link is 18 months old, in which he says "I expect it'll be two years before you'll need to learn Python 3.0", so if he followed the advice he should start learning 3.0.
Re:Probably not an issue for beginners? (Score:3, Insightful)
Philosophical. Pragmatists like myself can't stand it.
Re:Probably not an issue for beginners? (Score:4, Insightful)
The reason is consistency. If I have:
print "Hello world."
and
print("Hello world.")
Which do you suppose is easier to find-and-replace to:
o.write("Hello world.")
The second, of course, because you can do it without a wildcard.
Re:In all seriousness (Score:1, Insightful)
Worst is the cut and paste from one source into another.
So true, but for reasons that probably escape you.
Re:In all seriousness (Score:3, Insightful)
Guido made a major fuck up there- by removing braces but not strictly defining whitespace
Stop. First, the whitespace rule in Python *is* strictly defined.
The formal, exact, unambiguous specification of how Python interprets whitespace is in the official language reference - Lexical analysis [python.org].
It's pretty wordy, but I've studied it and it's quite precise. The relevant section is here:
"Firstly, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight"
This is exactly the same as the default behaviour of Unix `expand`.
[Guido has] created a language where it's possible to have two identical looking pieces of code do very different things.
It depends what you mean by "looking". To you, perhaps 1 tab looks the same as 4 spaces. To me, maybe it looks the same as 2 spaces. To Jeff, maybe it looks like a red dot in his specially-configured editor. To Python, it happens to look the same as 8 spaces.
DO NOT MIX TABS AND SPACES. Then, I guarantee you that any two pieces of code which look the same to you (whether they use tabs or spaces) will also look the same to Python. (You don't have to enforce this across a whole file, just on a per-block basis, but it's best if your whole project has an agreed indentation standard).
That's silly. Then you'd be at Guido's whim; you'd have to indent the way he chose. This way, you can choose any indentation you like. Tabs, 2 spaces, 4 spaces, 3 tabs if you like. As long as you are internally-consistent, Python will be happy.
My second point to you: If you are pasting code from somewhere into your code, and you do not fix up indentation so it matches the surrounding code, you are worse than Hitler. Or at least very lazy. I don't care if you are using Python or C or Brainfuck.
If you carelessly paste 1-tab-indented code into a surrounding block which is 4-tab-indented, and don't fix it up, then how do you think I will feel when I open it in my editor configured to expand tabs to 2 spaces instead. It will be totally unreadable -- and this is why we indent in the first place (in any language, that is).
Python forces you to tidy this up, and that can only be a good thing. If your code is confusing Python, it's probably confusing a bunch of other readers as well.
Re:In all seriousness (Score:4, Insightful)
This is easy to demonstrate
for i in myarray:
** Do some stuf here, use spaces to delimit. Note we are already inside a function or class. That is, we are not at the first indent level
print "Hello world" //Note this line is tab delimited. It looks likes its at the right indent level but its not.
Now you expect the code to print hello world a load of times but it will actually do it only once.
Its easy to extrabolate this to less trival problems