Python 3.3: Trust Me, It's Better Than Python 2.7 (2013) | Hacker News Reader

Python 3.3: Trust Me, It's Better Than Python 2.7 (2013)

speakerdeck.com

117 pointsglynjackson37 comments

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.

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.

And you forgot to add, the lack of API and support on a lot of products even on a fresh start-up. Check out for example, Google Data API 1.0 (GData 1.0) and GData 2.0 the newest. They have Python stuff for GData 1.0 (Google Data Python Library) using Python 2.5 in examples and zero libraries on Python in the GData 2.0 API. But even if they did build a library for Python 3.3, I would have to get DataNitro and a few others I love playing with to work on 3.

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

It is also guaranteed to be extremely stable, and will be supported nearly forever as some important libs just won't get ported.

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

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

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

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.

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.

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.

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.

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?

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?

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

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

I agree with you. I think it was a mistake to use punctuation, and I like the keywords that you propose.

There are a lot of awesome things that can be added to a language. Python is nice because it's simple and intuitive and you don't really need to read the docs to figure out how to do things and use libraries.

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.

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.

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

> 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 repo

* Most Python packages today are compatible with 2.6

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

At the facility I work at we're still migrating from Cent5 to Cent6. Cent5 is installed with Python 2.4 (released 2004-11-30, unsupported since 2008-12-19). Thankfully, we're juggling Python 2.5 and 2.6. We rely on a couple pieces of third-party software that include their own Python (2.6 and 2.7).

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.

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

> May I ask why?

A great deal of the Red Hat management tools use that Python, so it's not something I advocate altering beyond the python packages provided by RHEL/CentOS/Scientific Linux.

Yes I can use virtualenv, but by the time I'm going that far, especially in the event of deploying 100's to 1000's of hosts, having a separate installation just isn't so difficult.

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.

I haven't been able to find any good repo (recent, maintained, reputable maintainer) unfortunately. I usually end up compiling them myself. I was actually surprised how easy it is, nevertheless a (possibly official) repo would be _very_ nice.

Fedora has the ability to install python3 alongside the system python2.7, so there is probably an official rpm you can just pull from the Fedora repos.

edit: https://admin.fedoraproject.org/pkgdb/acls/name/python3

By the time you're looking at deploying to hundreds or thousands of hosts, it seems that you would be creating and controlling your own repo's. Thankfully building Python is straight forward, so building a rpm shouldn't be too painful.

Though it did seem odd that there wasn't already a repo for Python 3, so a little googling found this -

http://iuscommunity.org/pages/About.html

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

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.

concurrent.futures is available for Python 2.x.

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

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

That's actually great.

not without twisted.

Reply on news.ycombinator.com