Interesting 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.
The guy probably gave it as a lunch-time talk at Google, and their default slide format adds that footer. Google seems worse than average in terms of compulsive secrecy, but hardly unique IME. Labeling a summary of a public ChangeLog plus a few benchmarks "Confidential and Proprietary" is just what people do these days. But this seems kind of sloppy, especially if he's reciting from a company slide deck (I've seen Go…
Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
31–38 of 38 posts
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#32Whether 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.
Python 2.7 is a dead end regardless. Python 3 is the way forward.
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#33Earlier quoted context omitted.
I am, but I've never written one. Maybe it's best to start a discussion on the ML?
That is, in fact, the first step to a PEP! According to this: http://www.python.org/dev/peps/pep-0001/ :) Are you on the ML already?
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#34Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#35That's actually great.
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#36Can 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.
See http://www.python.org/dev/peps/pep-3107/ . 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.
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.
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#37Earlier quoted context omitted.
> CentOS6 defaults I've always considered it bad to use the RH provided python for development.
> 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 r…
But even without the third-party software I'd prefer to use a separate install of Python. If there were a few Python scripts there and there, we could probably manage, but managing a large Python codebase would be ridiculous trying to rely on the OS version of Python. Transitions to new OS versions would be way harder, too.
Re: Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)
#38Earlier quoted context omitted.
That is, in fact, the first step to a PEP! According to this: http://www.python.org/dev/peps/pep-0001/ :) Are you on the ML already?
No, I'm going to go register and join the discussion.