At the moment, Python 2 may be more productive, because it's got more libraries.
But the way things are going, Python 3 will soon reach parity, and eventually take over. If that happens, it was no longer a smart choice to go Python 2 for a new project. I'm not saying you should port old code anytime in the next few years (unless it's a library). But it's probably worth thinking about whether or not new projects should use Python 3.
spam = None
bacon = 42
def monty(a:spam, b:bacon) -> "different":
pass
Annotations provide a loosely organized way to introduce type checking to your inputs and outputs. They serve as built-in documentation and IDE hinting mechanism, but also provide the ability break early when the function's I/O contract is broken. IMO they are awesome and quite Pythonic.
The fact that the colon and right arrow in a Python annotation are, for the interpreter, a no-op, is insanely confusing to a newbie or just a generalist. It is compounded by how it would have made much more sense to reserve keywords in their places, so instead of
def foo( a : "fruit", b : Color) -> Pineapple:
you could have used reserved names:
def foo( a expects "fruit", b expects Color) returns Pineapple:
Which is a lot more readable in the way Python is meant to be. Good Python code reads more like prose than software, and the former prevents that from happening at all.
Now it's becoming more like C++, where each hotshot developer want to add his language extension to do some obscure thing nobody really uses except from them and their friends. It will be the demise of Python.
What about this instead: make it faster.
http://www.python.org/dev/peps/pep-3107/#use-cases
>> Despite yet more discussion, it was decided not to standardize a mechanism for annotation interoperability. Standardizing interoperability conventions at this point would be premature. We would rather let these conventions develop organically, based on real-world usage and necessity, than try to force all users into some contrived scheme.
I've always considered it bad to use the RH provided python for development.
May I ask why?
I see why maybe using your own compiled 2.7 or 3 might be nice, I don't, I just use the one that comes in with CentOS/RHEL 6.
* It get regular security updates from upstream
* Easy to install, it is part of existing package dependency chain (as opposed to say doing make ; make install from source)
* It comes with a default repo
* Most Python packages today are compatible with 2.6
Edit:
Python 3 may see more adoption if they provided .rpms and .debs directly. When you have to install python on 100s or 1000s of machines, doing them one by one is simply impractical.
It was dishonest to call it Python.
That's actually great.