Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

speakerdeck.com

Post reply on HN
Print view View original

21–30 of 38 posts

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

#21

Post by ak217 »

zanny wrote: post #14
ak217 wrote: post #11

Earlier quoted context omitted.

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,…

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

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

#22

Post by ak217 »

Mizza wrote: post #17
zanny wrote: post #14

Earlier quoted context omitted.

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,…

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?

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

#23

Post by rdtsc »

mhurron wrote: post #6
falcolas wrote: post #3

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

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

#24

Post by Mizza »

ak217 wrote: post #22
Mizza wrote: post #17

Earlier quoted context omitted.

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?

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

#25

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

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

#26

Post by mhurron »

rdtsc wrote: post #23
mhurron wrote: post #6

Earlier 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…

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

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

#27

Post by dded »

rdtsc wrote: post #23
mhurron wrote: post #6

Earlier 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…

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

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

#28

Post by ansgri »

sigzero wrote: post #20
freyrs3 wrote: post #5

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.

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.

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

#29

Post by shaneofalltrad »

freyrs3 wrote: post #5

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.

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.

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

#30

Post by keypusher »

pepr wrote: post #12
jsmeaton wrote: post #7

Earlier quoted context omitted.

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

Post reply on HN