

Python 3.3: Trust Me, It's Better Than Python 2.7 (2013) - glynjackson
https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-its-better-than-python-2-dot-7-by-dr-brett-cannon

======
freyrs3
Whether 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.

~~~
sigzero
Python 2.7 is a dead end regardless. Python 3 is the way forward.

~~~
pyre
Just like how Perl 5.x is dead and Perl 6 is the way forward? /s

~~~
ak217
Except for the part where Python 3 is real, production ready and about to
become the default.

------
mkl
Here is the video of this talk (40 min.), for those who don't like trying to
decipher slides: [http://pyvideo.org/video/1730/python-33-trust-me-its-
better-...](http://pyvideo.org/video/1730/python-33-trust-me-its-better-
than-27)

------
DonGateley
Don't need your word on that. It's pretty generally accepted that it is a
better language. It's that relative to what existed it is a new language, not
an upgrade. It is incompatible with the old one and most all that has been
written for it. Most who are invested already can't and won't go there. Most
who are coming into it choose to maximize their options over language nicety.
It's all just too problematic.

It was dishonest to call it Python.

------
Mizza
Can 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.

~~~
ak217
See
[http://www.python.org/dev/peps/pep-3107/](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.

~~~
zanny
Personal stylistic opinion here but while the concept of annoations is
pythonic, I think the implementation we got is the opposite. It uses magic
glyphs that require research to interpret - especially if you come from any
other programming language, because when you see things like a : b, or foo ->
bar, you expect that to have some syntactic meaning.

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.

~~~
Mizza
I agree completely! When I see a ':', I think slice syntax, and when I see a
'->', I think.. hashrocket? What is this madness?

Is anybody interested in working on a PEP about this?

~~~
ak217
I am, but I've never written one. Maybe it's best to start a discussion on the
ML?

~~~
Mizza
That is, in fact, the first step to a PEP! According to this:
[http://www.python.org/dev/peps/pep-0001/](http://www.python.org/dev/peps/pep-0001/)
:)

Are you on the ML already?

~~~
ak217
No, I'm going to go register and join the discussion.

~~~
cfqycwz
Hey, did this happen? If so, I'd love a link to the discussion .

------
falcolas
I'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).

~~~
mhurron
> CentOS6 defaults

I've always considered it bad to use the RH provided python for development.

~~~
rdtsc
> 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

~~~
dded
> May I ask why?

Independence. When you upgrade to RH7, you don't need to worry if all your
scripts will run with Python 2.7, they'll still point to your own 2.6. You can
decide to upgrade to 2.7 (or not) on your own time. You can do it before or
after your migration to RH7; they're independent decisions. Even ignoring
Python3, Python occasionally breaks backwards compatibility (the deprecate,
warnings, then errors dance). It's nice to control your own situation.

But our programs are internal-use only. So we don't have the same concerns
with security updates, ease of deployment to customers, etc., that you may
face.

------
allochthon
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.

~~~
username223
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 Googlers do this even at
respectable academic conferences).

~~~
prostoalex
Seems a bit sloppy on their end and ripe for social engineering trickery. If
an employee is debating publishing/sending something labeled "Confidential and
Proprietary", but then sees a dozen of "Confidential and Proprietary"
documents in Google-approved public repositories, they might lower their guard
on what the words actually mean.

------
human_error
concurrent.futures is available for Python 2.x.

~~~
djrobstep
Yes, thank god. concurrent.futures is a brillant library, makes writing
multithread/multiprocess code so much cleaner and more intuitive

------
AzioMurad
"All .pyc files now kept in a __pycache__ directory"

That's actually great.

------
the1
not without twisted.

