Posted
by
ScuttleMonkey
on Monday January 12, 2009 @04:02PM
from the all-growd-up dept.

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

Hmm, thanks for that little tip. I still have the leaked NT code from around 2004, and linking to that (granted it remained the same) might just be a good practice for some POSIX-esque cross-windows features, perhaps even undocumented, in future apps. Thanks!

No Twisted? Well, no Python 3.0 for a bunch of my apps for a while...I did mention Django, though, specificially because the Django devs have no definitive plans to update it 3.0 at this time and it's not inconceivable that they might never update it for 3.0.

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.

The obvious reason is to provide a consistent I/O class hierarchy where standard output is inherited from some other general stream.

Another common reason (I don't know if directly applicable in this case) is to dynamically assign behavior. Say you have an object and you will call its method named m="f" (that value/method-name is resolved at execution time), so you may execute sort of object."f"(). If the concrete needed action is a data printing, then you could set m="print" and that's all. But being print

Can someone tell me why it was changed to print()? Philosophical reason or pragmatic?

One reason for the change is simply that a language should be consistent and with print() it becomes that, since it turns print() into a usual function. The old print statement on the other side was pure magic, stuff build into the syntax of the language that is different from any normal function for no good reason. And that kind of magic is something you want to reduce to a minimum, since its ugly and just makes your language look weird.

They will matter a little bit. Some very basic things (like the way the print function works) have changed. However, there's plenty of information on their website, and they've made tools to make migration easier. Those little problems should be easy enough to work around if you use 3.x, or you could keep using 2.x for a while until everything else catches up.

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.

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.

Like basic grammatical structure, for instance? When did Palin become a Python dev?

For those interested, IBM is running a primer series [ibm.com] on the new language/runtime features.

There's also this [python.org] 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 [slashdot.org] the the actual moment in time when 3.0 was let loose on the world. I'm such a sentimental geek:)

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.

If you don't care about unicode that much (e.g. you mostly deal with development tools, iso-latin1/ascii encoded files...) there is absolutely no rush to hop on the bandwagon. And perhaps you just hate unicode as a concept;-).

I predict that the bandwagon will start rolling ~ Q2 / 2009, when toolkits like PyQt4 for 3.0 are materializing.

Of course the list would be pretty long (good thing I don't have to list it [python.org]), and of course Unicode is very significant, but I think there are other things just as significant if not more. Example: everything's an iterator now, not just a list.

BTW, Python 2.x has all the unicode support you need to write a correct application. You just have to use u'unicode strings' instead of 'strings' in a lot more places. Python 3.0 has just switched the default, which will make it easier for application developers to

I posted about this before in a previous Python 3.0 article and a lot of people attacked me. However I very much feel that Pythons treatment of Unicode as UTF-16 is a HUGE problem that will cause no end of pain. I think a far cleaner solution to Unicode is to do the following:

- Make unmarked plain quoted strings produce byte strings just like they do now. Unless there are backslashes, the contents are precisely the bytes that are in the input file. Keep the automatic casting of byte strings to unicode strin

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 [cmlenz.net]). 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

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.

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.

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.

Parent is right. It sounds daunting before you actually work with it all the time. But in practice, you set up your editor to do the right thing, and it's never a problem again for you except like once every few months.

And posting code on forums, or any other place that doesn't assign meaning to invisible characters. Python is like the cat of programming languages... always freaking out about some imaginary thing. You'll be writing your code all nice and friendly like and then accidentally hit tab instead of spaces and then out of the blue Rrrwrwr!

Both are much less common than looking at badly-formatted code that it takes a bit to mentally parse which brace-delineated languages have.

Any programming editor has a simple command to reindent or reformat the code. If you're writing your program in Word you're in trouble no matter what language.

The whitespace issue is a red-herring: most people get used to it quickly

You have data to back this up, I assume? I'm not certain that the majority of people I know using python hate the whitespace retardedness, but I know it's not a "red-herring" and it's far from 90%+ of people who don't hate it (people either don't care or hate it, with a very few who thinks it's a great idea... IME).

I was always a fan of the white space.Having worked with a lot of languages. Forcing good form is actually a nice feature, when the language doesn't enforce proper layout of application of any size will undoubtedly start getting sloppy. Adding an If statement or a while loop as a bug fix and not taking time to properly indent is quite common. And over say 20 years life span of an application, those simple fixes become sloppy code that is hard to read.

BTW, I like Python (and have almost given up on Perl 6), but the white space thing drives me crazy.

I suppose there is no reason someone couldn't write some SVN hooks that would automatically add curly braces to Python code as it was being checked out from the repository, and automatically remove them again (and correctly indent the text) as Python code was being checked back in. And, of course, update the Python interpreter with a flag to optionally require curly braces instead of indentation, as a way of

Except of course that making copy&paste hard is doing the exact inverse of that philosophy, since it makes refactoring code hard, you no longer can move code around, slap a function name on top and be sure it will work afterwards, in Python you have to be extremely careful not to break any whitespace or the code might break in very non-obvious ways.

No, this does not refer to code duplication, but rather copying someone's code from a forum (where you might post your code for error inspection) becomes tricky due to whitespace mangling. Alternatively copying a bit of code into another file for testing only a small section of the program can become error prone.

Code reuse on the other hand is something to be encouraged wherever it is practical and useful.

No, unfortunately they did the worst thing they could do in that respect. Nearly all the changes introduced will make longer lines of code. I think they are trying to make sure that you will need to use the line continuation backslash, which completely negates the advantages of whitespace formatting.

It seems that their definition of "clean syntax" is Java-like, rather than Perl-like. I never went to the extreme of playing "Perl Golf" [wikipedia.org], but a

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

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

As a KDE fan, I have to say just how jealous I am that other software development communities actually have common sense.

Apache: "Our newest is Apache 2, but you can use our rock-solid Apache 1 if you want."Python: "Our newest is Python 3, but you can use our rock-solid Python 2 if you want."KDE: "What!? You're still using KDE 3? But we told all our developers to drop all KDE 3 and move on to our newest KDE 4, which just came out with the second release candidate version of the beta for our alpha version!

Backwards compatibility is good but it was never a part of the plan for Python 3 from the beginning - that was declared from the start and has been known for years. 2.6 and 3.0 were released close to each other. The biggest worry I have is that 3.0 is SLOWER than 2.6 in the benchmarks I have seen.

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 1

The problem with whitespace is that it breaks code. Take a snipped of code copy it and paste it into a different indention level. In a block oriented language the code will continue to work exactly as intended and at no point will the code be invalid. In Python on the other side the code breaks as soon as you paste and you have to move that broken code back into usable form manually. Now a proper editor can help with that, but it won't stop Python code from temporarily break.

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.

The point is that is a flawed design that promotes inadvertent errors in code just like C's '=' and '==' operators are too easy to carelessly mix up (especially when switching between other languages that use '=' for equality tests). I like Python and the white space delimiting is liberating but it is unfortunately implemented in an ad hoc way that is susceptible to easily missed breakage. A better language wouldn't depend on the sort of higher level practices you suggest to guard against these sort of mist

Gawd, you all do realize that the code needed to re-deliminate python code to braces instead of spaces or tabs is about half a page right? You can have it both ways.
Hint: Every time you hit an open bracket, increase a value by four. this value is the number of spaces before each line except where the line ends in '\' (a line continuation character). When you hit the close bracket, you decrease the number of spaces you emit by four.
Simple, no?

for whitespace bugs in python. If your programmers insist on using their own personal editors with their own personal tab expansion preferences - then ban tabs. All fixed. Easily automated. Use a CVS script to reject *.py with tab chars.

I have also been bitten by C bugs caused by white space. Someone with a different tab stop had entered the code incorrectly, but it looked correct in my editor (with standard unix 8 space tab stops). Never did notice the misaligned brace until running it through pretty

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.

Agree completely. Though I have a heavily brace-oriented background, I've found learning Python while ignorant that you could use braces to contain code blocks, I've embraced the tab delimitation completely.

I've simply never had a major tab problem, and while I don't write terribly complicated code, I nest the hell out of things sometimes. I develop on Windows and use PythonWin and there's just never a problem with indentation. I totally don't get people who troll (not accusing you!) on the topic.

Guide: Hmm, should I use spaces or tabs for indentation?College 1: Spaces, of course. Spaces look the same everywhere!College 2: I disagree. One space is too small to visually indent code. Tabs FTW!Guide: Why, I'll just do both.

Gawd, you all do realize that the code needed to re-deliminate python code to braces instead of spaces or tabs is about half a page right? You can have it both ways. Hint: Every time you hit an open bracket, increase a value by four. this value is the number of spaces before each line except where the line ends in '\' (a line continuation character). When you hit the close bracket, you decrease the number of spaces you emit by four. Simple, no?

I'm still a diehard C coder at heart, but I'll admit that braces as a syntactic measure are just plain bad (unless you're in a Lisp-variant, where a paren _is_ the whitespace, ffs). It's why reference-counting is insufficient for being a singular GC mechanism, and why, if compilers were built like garbage collectors, work efficiency would plummet [xkcd.com].

Seriously, a decent editor that can swap out tab commands for a N-length block of spaces w

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

Are Linux distributions that include packaged python versions and apps going to permit both 2.x and 3.x python versions to co-exist so all the apps (including local additions) don't have to be ported on the same day?

Fedora is trying hard to avoid that, because it is so difficult to have two versions installed in parallel. All python modules will have to be available in two (or more) versions, which is a royal pain.
However, it is not clear that avoiding it will be possible, so a decision hasn't been made yet.

Of course, raw beginners don't know that % means format, but there was a time when I didn't know that / means division either. Will they deprecate all operators because they might confuse a beginner? I think there should be some reasonable limits to that everything-is-an

WTF?! This notation makes the format string appear more important than the actual value. One could argue that the same happens in the old-style Python notation ("%7.3g" appears before the "10"), but that's just an artifact of the example and the old-style Python code is much more powerful.

Yes, you're right. After reading PEP 3101 [python.org], I have to agree that the new style is better.

Your short example tripped me up, but
>>> "User ID: {uid} Last seen: {last_login}".format(... uid="root",... last_login = "5 Mar 2008 07:20")
is very readable. Even though I think that "format" is a poor choice for the method name because you're doing more than string formatting, don't you?