Slashdot Mirror
The Evolution of Python 3
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."
and make everyone happy with Python 5.6
Shouldn't that be intelligent design? Otherwise we'd have way more python flavors.
I don't think will be a problem any more
I just started learning Python a few weeks ago when I got laid off from my QA job. I imagine I'm not to the point yet where the language differences between 2.x and 3.x are going to matter?
-- http://ninthagenda.com/
There's a couple of things that trip over beginners have been removed.
Ah, yes, I remember python tripping over me. It's actually pretty impressive that a snake figured out how to trip, why take out that feature? It seems like you're knocking it back a notch in the evolution toward legs.
The name Python originally came from Monty Python, so you're about 18 years late on that joke.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
For those interested, IBM is running a primer series on the new language/runtime features.
There's also this older (but still relevant) PEP that explains things that did not change between the 2.x series and 3.0.
Personally, I'm not looking forward to migrating existing code bases (especially non-trivial ones) to 3.0, but I'm planning to do all new development against it (of course assuming that the various packages I use have ports).
For Python trivia lovers, here the the actual moment in time when 3.0 was let loose on the world. I'm such a sentimental geek :)
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
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 )).
The above sentence fragment is apparently a verbal quotation where Guido van Rossum forgot he used the word "if" when he was somewhere in the middle.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
I don't think so. One of the design ideas for python, IIRC, was to force "proper indentation" for "proper documentation".
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.
So whitespace block delineation is finally out, in favor of braces? :P
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
I think that whenever a group releases a new version of their language, they should strive to make it (mostly) backwards compatible. Not only does Python 3.0 change the way things work in relation to specific function, but it also removes specific language conventions and creates new ones in their places. This means that very large projects have a lot of work to do to bring their project over to the new specification.
The question is: is this work worth the upgrade to python 3.0? I'd say on the whole, the changes do not contribute enough to the usability of the language to make it ultimately a worthwhile transition to make. I haven't seen really any compelling features in Python 3.0 that would provide enough incentive for me to spend hours of grunt work making all my code workable in Python 3.0.
</my two cents>
Web Hosting: Unlimited storage and bandwidth: $5/month
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.
I still have more fans than freaks. WTF is wrong with you people?
Yes.
Example program:
class MyClass(object): #{
def myfunction(self, arg1, arg2): #{
for i in range(arg1): #{
print i
# whoops, forgot to close that bracket!
#}
#}
Save your wrists today - switch to Dvorak
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.
I currently have both python2.4 and python2.5 installed in Ubuntu. They're different packages, and can easily be installed alongside each other.
For distributions with dependency management (Ubuntu, Debian, Fedora, any modern distribution), this isn't a hard issue -- in the distros I'm familiar with (Debian/Ubuntu) the different versions of python are just separate packages, apps have a list of dependencies and can list that they depend on a certain version of python, and the python package is just a dummy package that "depends" on the latest version of python.
The same thing is done with different versions of Java, GTK, etc. When a toolkit or language makes a huge backward-incompatible change, it's rare that they can't just be installed alongside each other. Different 2.x versions of Python work just fine alongside each other, and I don't see how Python 3 would be any different.
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.
have you been seen on slash?
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.
Property for sale in Nice, France
There is a standard
I'm the guy with the unpopular opinion
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.
A good editor should re-indent the pasted code automatically. In VIM you can use :set ai, si.
Free Manning, jail Obama.
I've read your previous posts. You weren't making any sense back then, and you aren't making any now either. However, for some reason your trolling seems to go well with the mods every time.
It's a fact that the Unicode support in Python is not perfect (see e.g. this post). However, every and any issue you might have with Python 3 internal representation of Unicode strings, you are bound to have with Python 2 as well. The only thing that has changed is that the unicode and str types got replaced with str and bytes types respectively, and that you can't mix the two anymore without explicitely encoding/decoding them. And both of these are good things (TM).
Also, for someone who has supposedly spent so much time investigating Python Unicode support to great depths, it's rather funny that you don't know that Python does not use UTF-16 for internal representation of Unicode strings. It uses either UCS-2 (the default) or UCS-4, which are both fixed-length encodings. Unfortunately, the default one cannot represent characters outside the Basic Multilingual Plane, but hey - neither can say Java.
And finally, your argument that "real Python programs need to handle arbitrary data that is *PROBABLY* UTF-8." is utter rubbish. If you need to handle non-ASCII textual data you either:
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.
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.
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