>it was actually a bit worse than Python 2 when it was out

It still has a few things that really suck!

The thing that bothers me the most is the removal of in-argument tuple unpacking. For example, in python 2.x you could write:

dist = lambda (x1,y1),(x2,y2) : math.sqrt((x1-x2)2 + (y1-y2)2)

Whereas in python 3.x you must write

dist = lambda p1,p2 : math.sqrt((p1[0]-p2[0])2 + (p1[1]-p2[1])2)

Which is just awful to read. It gets much worse when you're trying to program in a functional style and you are using triples or quadruples. Imagine using "x[1], x[2], x[3], x[4]" instead of something like "length, width, height, color".

PEP 3113 attempts to rationalize this change, but it's kind of an awful PEP. It claims "no loss of abilities removed", which is clearly false, and the proposed benefits are highly specious. The entire tuple-unpacking system could just be reduced to the insertion of an unpack instruction at the start of the function. That would actually make a lot of sense with Python's policy of "ask forgiveness rather than permission", since trying this with the wrong tuple length would throw a ValueError explaining what went wrong.

I also miss (but it's not really an important language feature like in-argument tuple unpacking) the ability to do encoding directly on strings. For example,

"hello".encode('hex')

or

"aGVsbG8=".decode('base64')

That was much more convenient than having to import some library and use library methods.

Try Python 3.4

I agree with the sentiment, and 3.2 had some rough edges still, 3.3 is better and 3.4 finally gives a virtualenv similar (or even better) to Python 2

Still sucks when youve got modules with c extensions, lile any usable fast module, the virtualenv doesnt virtualize that.

uwsgi (as an example) has C components and builds/installs on a virtualenv

print as a function made it into Python 2.6 (using future imports). It's probably one of the more purely stylistic choices in 3.X. The function style is probably better for pretty much all shipping code (as opposed to someone typing at an interpreter).

The Unicode switchover is where all the pain is, and it isn't particularly clear that there is a good way to do such a thing.

I for one like the 2.x style print function. I see why it would be a bad idea to have a separate syntax for print from a purist point of view.

But least for smallish scripts which print a lot it give you a better overview because the print line look different than other lines. Sometimes prints can almost be like comments.

> I for one like the 2.x style print function.

2.x didn't have a print function, unless you mean the one from 3 available with a from __future__ import.

In case the grandparent doesn't realize, 2.x has a print statement not function.

I meant function as in functionality. This is really pointless nitpicking.

Knowing the difference between functions and statements is not pointless nitpicking. Not in the least.

Normally I would agree with you - but one of the epic changes between 2.x and 3.x python, was the change of print from a statement to a function - so, in this case, it's not so much nitpicking as pointing out one of the major changes between the two streams of python.

In python, they are called "functions" whether or not they have side effects. (And, actually, in most programming languages I've seen that have different constructs called "function" and "procedure", the difference is that functions have a return value and procedures don't -- usually, both can have side effects.)