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

Comments

Combine them....

[thetoadwarrior]

and make everyone happy with Python 5.6

Re:Combine them....

[morgan_greywolf]

Lemme guess... you're a student of the Sun Microsystems'-sponsored Bill Joy School of Version Numbering?

Re:Combine them....

[Radish03]

Either that or he's a Winamp developer.

Re:Roland Piquepaille: a case study in madness

[Anonymous Coward]

I don't think will be a problem any more

Trip over beginners?

[AaxelB]

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.

Re:Trip over beginners?

[lewp]

Well, Common Lisp stole my bike.

Re:Probably not an issue for beginners?

[morgan_greywolf]

Unless you're trying to learn how to code Django apps, which won't work on Python 3.0. Neither will a lot of other 3rd party modules.

Re:Probably not an issue for beginners?

[Random BedHead Ed]

Not really. Keep learning 2.x as you were. Quoth Guido:

http://www.artima.com/weblogs/viewpost.jsp?thread=211200

Ignore 3.0 for now. If you encounter it, there is a handy script to help update your code, though most of the language is unchanged. The biggest gotcha is that print is now a function print() rather than a statement.

Getting into Python 3

[dedazo]

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 :)

Oh good.

[powerlord]

There's a couple of things that trip over beginners have been removed.

So whitespace block delineation is finally out, in favor of braces? :P

Re:Oh good.

[SatanicPuppy]

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:

while(...){if(...){if(...){}elseif(...){}}}

That's clearly the suck, so we break it out like:

while(...){
    if(...){
          if(...){
          }elseif(...){}
    }
}

...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:Oh good.

[hwyhobo]

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.

[costas]

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:Backwards Compatibility

[ultrabot]

I think that whenever a group releases a new version of their language, they should strive to make it (mostly) backwards compatible.

That's why they keep releasing 2.x versions that are backwards compatible.

This means that very large projects have a lot of work to do to bring their project over to the new specification.

Very large projects can stay with the 2.x series (along with a big portion of users) just fine.

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.

And you shouldn't, since it would probably be a waste of work. 2.x is a rock-solid series that is years away from obsolescense, and new serious projects started right now should pick 2.5 / 2.6. Try starting to use Py3 for projects where it fits - your command line scripts, self-contained internal applications... and ramp up the stakes when new libraries are ported.

A programming language deserves a "cleanup" every now and then - this is such a thing. Hey, people have survived worse things, like gcc version changes, Qt3 => Qt4, Gtk 1 => Gtk2...

Re:In all seriousness

[AuMatar]

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:In all seriousness

[ultrabot]

Yes.

Example program:

class MyClass(object): #{
        def myfunction(self, arg1, arg2): #{
                for i in range(arg1): #{
                        print i
                # whoops, forgot to close that bracket!
        #}
#}

Re:In all seriousness

[Anonymous Coward]

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:In all seriousness

[horza]

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

[AlexMax2742]

There is a standard

Re:In all seriousness

[SleepingWaterBear]

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?

[dodongo]

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

[jibster]

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