Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
speakerdeck.com
Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
1–10 of 38 posts
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#2concurrent.futures is available for Python 2.x.
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#3I'm sure it is. Still doesn't address reasons I can't migrate to 3.3, though (those being CentOS6 defaults, lack of packages, cost/benefit ratio too high for migrating).
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#4Interesting read. Note the "Google Confidential and Proprietary" at the bottom of most of the slides. I wonder if the author just forgot to remove the notice when the slides were made public.
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#5Whether it's technically better or not is usually not in question. It's whether it's compellingly better to the point of outweighing the migration cost. For most of the community it still seems the answer is no.
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#6I'm sure it is. Still doesn't address reasons I can't migrate to 3.3, though (those being CentOS6 defaults, lack of packages, cost/benefit ratio too high for migrating).
> CentOS6 defaults
I've always considered it bad to use the RH provided python for development.
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#7I'm sure it is. Still doesn't address reasons I can't migrate to 3.3, though (those being CentOS6 defaults, lack of packages, cost/benefit ratio too high for migrating).
> CentOS6 defaults I've always considered it bad to use the RH provided python for development.
True, but are there any decent repos for installing python3? Even with 2.7 I generally have to build it myself. I loathe having to use RH5 and RH6 due to how old they seem.
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.
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#8Can somebody explain function annotations for me?
spam = None
bacon = 42
def monty(a:spam, b:bacon) -> "different":
pass
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#9Can somebody explain function annotations for me? spam = None bacon = 42 def monty(a:spam, b:bacon) -> "different": pass What's the point of this? It also seems like super ugly syntax to me, not pythonic. It looks like Ruby! Yuck.
It's typically used either for additional documentation or for type inference (like for IDEs, static analysis). Only the fact that you can annotate parameters/return types is implemented. This was basically done to see how annotations would evolve in community use.
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.
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#10Whether it's technically better or not is usually not in question. It's whether it's compellingly better to the point of outweighing the migration cost. For most of the community it still seems the answer is no.
It's hard to write libraries in both versions.
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.