sep is the separator between arguments, so you can do something like:

    >> print('a','b','c',sep='')
    abc

file lets you specify a file to print to, so for example you can do file=sys.stderr to print to stderr instead of stdout.

print "comma prevents a newline from being printed",

print >> sys.stderr, "Any file object can be used"

The change to a function is purely for consistency, not functionality.

http://docs.python.org/2.7/library/functions.html#print

  from __future__ import print_function

  map(print, [1,2,3])

  def test(*a, **b):
    print(*a, **b)
  
  test(12)
  with open('t.out', 'w') as f:
    test(12,13, sep='--', file=f)

If you're doing greenfield development, and don't plan on lots of external dependencies, use 3. Personally, if I didn't have dependencies on a few "really big" external libraries, I would be running 3 in production.

This wiki page - a work in progress - should help you if you're thinking about switching.

http://wiki.python.org/moin/Python2orPython3

Even under considerable load, the traditional Apache/mod_wsgi combination never failed (though we had some encoding issues during development).

The reason to go p3 was for one the new string handling, which I personally find absolutely beautiful and the idea of future proofing the application. We are a small shop and certainly don't have the resources to rewrite the thing in 3 years when all the cool stuff is happening in python 3 land.

This was also the reason to start development of another application in PHP5 just when 5.0.0 came out. There it paid off, though with p3 I'm not quite sure. It looks as if we are stuck with 2.x maybe forever.

Also, Ubuntu ships with 2.6 and I'm too lazy to switch

If are starting from scratch it might be OK. I guess it depends on your needs for library support.

IMO it was a bad idea to split development like they did. But I am just a user and not in charge. :)

If it was me I would pick 2.6

The most impressive things that might push us to upgrade are the new VMs like unladen swallow or PyPy, assuming they don't get backported support for 2.7ish style python.

But right now, most libraries are made for 2.x only, and there isn't yet a large enough performance or memory use gap to force us to take the porting hit.

http://svn.python.org/view/python/branches/py3k-jit/

When I make the jump, it will probably be to the inevitable 3.5 or 4.0 that includes all the juicy stuff.

For me, it's simply "I just need my dependencies" - which is a simple statement, but an incredibly hard problem.

I have (in small parts) contributed to the python 3 conversion for numpy/scipy, and the only reason why I have done so is to be a good "python citizen", and because numpy is a major library in the python ecosystem. But I don't see any advantage in doing so. The cost is high, and the advantages near inexistent for me

Function annotations, the standard library cleanup, and other things came along for the really big ride, which was the bytes/unicode/etc ride. So, there's lots of improvements that came with 3.0 - but the nice thing is is that it continues to evolve.

We now have a New (more rational) GIL, we're probably going to have a futures package (http://www.python.org/dev/peps/pep-3148/) and so on (heck, python3 is also getting a jit). And things will continue to be added. Everyone knows and admits that the transition will take years, but now with 2.x being "done" (meaning, no more releases past 2.7) and more great work being done in 3.x, hopefully people in general will start to see the benefits.

Also, the funny thing with the GIL (even as the maintainer of multiprocessing) is that it's never bothered me. I've used hundreds of threads working with Queues/etc all the time. I actually don't use multiprocessing as much as I use plain old python threads.