Live data from Hacker News

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

speakerdeck.com

11–20 of 38 posts

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

#11
post #8

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.

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

#12
post #7
post #6

Earlier quoted context omitted.

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

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.

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

#14
post #11
post #8

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.

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

#17
post #14
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 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?

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

#18

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

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

#19
post #7
post #6

Earlier quoted context omitted.

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

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

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

#20
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.
Post reply on HN