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

Combine them....

[thetoadwarrior]

and make everyone happy with Python 5.6

Re:

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

[morgan_greywolf]

Same thing.

Evolution?

[El_Muerte_TDS]

Shouldn't that be intelligent design? Otherwise we'd have way more python flavors.

Re:

[Abreu]

Well, Python has a distinct, well known creator, so I guess it does qualify

Re:

[Anthony_Cargile]

It depends on if Python can actually fork() on Windows yet without using Cygwin.

Re:

[Anthony_Cargile]

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!

Re:

[wilder_card]

There were a lot more flavors, but 3.0 and 2.6 ganged up and ate them all. Don't even ask about poor version 3.14159...

Re:

[Shadow Wrought]

Don't even ask about poor version 3.14159...

I hear it bit its tail and now just slowly slithers around in a circle...

Re:

[flyingfsck]

"Python species"

There, fixed it for you! ;)

Probably not an issue for beginners?

[NinthAgendaDotCom]

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?

Re:

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

[ultrabot]

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.

Sounds like FUD - Django will update to 3.0, it will just take time:

http://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3-0

The upgrade won't be exceedingly hard either. It could be done people not part of the django core team, even... Summer of code 2009?

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 [artima.com]

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.

Re:

[Otter]

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

Philosophical. Pragmatists like myself can't stand it.

Re:

[DiegoBravo]

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

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:

[mgiuca]

o.write("Hello world.\n")

print has an implicit '\n' at the end. Gotcha :)

Re:

[Just Some Guy]

The reason is consistency.

I agree, but for different reasons. Since old-Python's print is a statement, you can't pass it around to other functions. Instead, you have to write a named wrapper function to execute it:

>>> def dosomething(function, value): function(value)
...
>>> dosomething(print, '234')
File "<stdin>", line 1
dosomething(print, '234')
^
SyntaxError: invalid syntax
>>> def printfunc(value): print value
...
>>> dosomething(printfunc, '234')
234

This is incredibly annoying a

Re:

[grumbel]

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.

On a more practical point of view, you can now write:

a = print
a("Hello

Re:

[joetainment]

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.

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:

[VirusEqualsVeryYes]

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?

Re:Trip over beginners?

[lewp]

Well, Common Lisp stole my bike.

Getting into Python 3

[dedazo]

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

This sentence fragment.

[HTH NE1]

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.

Re:

[MichaelSmith]

Its going to be a pain getting the indenting right in there.

Re:

[atraintocry]

If you code in Notepad, maybe :)

Unicode & toolkits

[ultrabot]

Python 3 mostly changes things that deal with unicode (i.e. it uses unicode an it's "text" object, like Java).

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.

Mostly? There's a lot else

[xant]

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

Unicode

[spitzak]

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

Re:

[omuls are tasty]

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

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:

[Unoti]

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.

Re:

[cryptoluddite]

There's two real-world problems with it: copy-and-paste and generating Python code.

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.

On the other ha

Re:

[Nevyn]

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

There's two real-world problems with it: copy-and-paste and generating Python code.

Err ... and let's not forget that

Re:

[jellomizer]

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.

Re:

[Jeremi]

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

Re:

[bitMonster]

Somebody wrote an encoding module to support braces in python code as kind of a joke. It's called pybraces [timhatch.com].

The code that implements it is surprisingly short [timhatch.com].

Re:

[mgiuca]

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.

Why would you want to mess up the indentation?

Re:

[he-sk]

If you use Notepad, that is.

Re:

[cibyr]

Cut-and-pasting then. It's still a problem (though one that should be solved by the editor, not the language IMHO).

Re:

[krischik]

That's the reason (well, one of them) why Python lacks block delimiters: messy code indentation in other languages.

Only I move on to automatic code formatting: Cut-Copy-Auto_Format and all is well. Now that won't work in Python.

Python strange syntax is solving a problem for in the mean time better solution where found.

Re:

[grumbel]

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.

Re:

[robot_love]

Wow. I've read a lot about coding and programming, but that's the first time I've ever seen someone claim that a programmers reluctance to copy and paste was a bad sign.

Methinks you have chosen a rather strange hill to die on...

Re:

[Spacelem]

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.

Re:

[krischik]

Of course I would use:

while ... loop
if ... then
if ... then
null;
else
null;
end if;
end if;
end while;

Knowing at the end of an block which block ends is nice and can lead to more intelligent error messages.

Of course braces don't give you that advantage either. They are indeed completely useless and g

Re:

[Kingrames]

No,theyremovedthewhitespace,butdidn'taddanybraces.

Unfortunately not

[mangu]

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

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

Re:

[Just Some Guy]

Python was almost there, the perfect compromise between readability and conciseness. Until 3.0, when they went astray...

So what, specifically, don't you like about Py3K? I've appreciated what I've seen so far. I don't mean that as a troll - I'm genuinely curious. What's less readable or concise for you?

Backwards Compatibility

[zwekiel]

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

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:

[MSG]

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

Not to mention Perl4 -> Perl5.

Re:

[dkf]

Hey, people have survived worse things, like gcc version changes, Qt3 => Qt4, Gtk 1 => Gtk2...

Not to mention Perl4 -> Perl5.

Or Perl5 -> Perl6...

(The bane of my life has been glibc versioning. Brought to you by the "Stable ABI? What's that?" school of programming.)

2.6 just as well supported as 3.0? I'm jealous!

[KWTm]

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!

Re:

[negative3]

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.

Re:Roland Piquepaille: a case study in madness

[Anonymous Coward]

I don't think will be a problem any more

Re:

[LighterShadeOfBlack]

The name Python originally came from Monty Python, so you're about 18 years late on that joke.

Re:

[bb5ch39t]

I don't think so. One of the design ideas for python, IIRC, was to force "proper indentation" for "proper documentation".

Re:

[Anonymous Coward]

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.

Re:

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

Re:

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

[grumbel]

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.

Thats Python is extremely lax wi

Re:

[he-sk]

A good editor should re-indent the pasted code automatically. In VIM you can use :set ai, si.

Re:

[DragonWriter]

A proper language would use an easily distinguishable delimeter- anything other than a whitespace.

All programming languages higher level than machine code that I've encountered, except for a few esolangs, use whitespace as a delimiter.

Re:

[Count Fenring]

Is lisp an esolang now?

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:

[wiredlogic]

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

Re:

[Coryoth]

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

May I suggest you try Ada or Eiffel then, which go to some trouble to try and weed out any such errors as early as possible (usually at compilation time).

Re:

[compro01]

For the "=" and "==" thing, do equality tests backwards, like:

3==foo

If you accidentally put

3=foo

It'll throw an error about an undeclared variable (presuming you don't have a string variable named "3") when you try to compile.

Re:

[StormyWeather]

If you don't like the built in editor, I've enjoyed the Easy Eclipse for Python distribution as well.

http://www.easyeclipse.org/site/distributions/python.html [easyeclipse.org]

Re:

[TheCouchPotatoFamine]

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?

There is no excuse...

[CustomDesigned]

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

Re:

[Moebius Loop]

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 a

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

Re:In all seriousness

[AlexMax2742]

There is a standard [python.org]

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:

[dodongo]

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.

I had no Idea

[jgtg32a]

Um my bad on starting this little flame war I had no idea.

Re:

[mgiuca]

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

Re:

[gullevek]

I completely disagree. He should have made tab mandatory. Not space. This would have made it all much easier. Because 2 spaces, 3 spaces, look all very similar. but one tab is one tab.

Re:

[he-sk]

I bet the though process went something like this:

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.

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:

[KovaaK]

Sweet. Now with all that work that you've done in getting python to support braces, can you make it not depend on whitespace? I'm sure it won't take that much more effort.

Re:

[ultrabot]

can you make it not depend on whitespace? I'm sure it won't take that much more effort.

It would be easy to create a preprocessor to do that, but life's too short. I'll leave the excercise to someone that cares enough.

Re:

[TheCouchPotatoFamine]

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?

Re:

[ins0m]

echo "set et ts=4 sw=4" >> ~/.vimrc

You'll thank me in the morning.

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

Re:

[joe_cot]

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

Re:

[amorsen]

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.

I agree....

[mangu]

There's no way an Intelligent Designer could think that

>>>print(format(10.0, "7.3g"))
10

is a clearer syntax than

>>> print '%7.3g' % 10.0
10

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

Re:

[spiralx]

Or use

print("7.3g".format(10.0))

like every normal person would.

Re:

[Kent Recal]

It's still more visual noise. Imho the '%' syntax should stay the way it is - it's quick to type and easy to parse for a human.
Furthermore it'd be great if they would add perl-style =~ regex-matches.

Other than that they can objectify all they want, as far as I am concerned.

Re:

[he-sk]

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.

Re:

[spiralx]

No, the new style formatting is more powerful:

"First, thou shalt count to {0}" # References first positional argument
"My quest is {name}" # References keyword argument 'name'
"Weight in tons {0.weight}" # 'weight' attribute of first positional arg
"Units destroyed: {players[0]}" # First element of keyword argument 'players'.
"Harold's a clever {0!s}" # Calls str() on the argument first
"Bring out the holy {name!r

Re:

[he-sk]

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?

Re:

[he-sk]

Accidentally hit the submit button.  The code should be

>>> "User ID: {uid} Last seen: {last_login}".format(
... uid="root",
... last_login = "5 Mar 2008 07:20")