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

Python 3.5.0

python.org

Post reply on HN
Print view View original

91–100 of 165 posts

Re: Python 3.5.0

#91

Post by jay_kyburz »

wfunction wrote: post #89
redsymbol wrote: post #34

Python 3 keeps getting better and better. I've been writing more code in Python 3 than 2 for about three years now, and I absolutely love it. When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second.

> When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second. You mean, second gear up to fifth? I tried writing some Python 3 code and the lack of parameter tuple unpacking by itself stunned me and drove me crazy, never mind other stuff. Python 3 seems very user-unfriendly compared to Python 2. Won't touch it with a ten foot pole unless my life depends on it.

Probably means from 3rd gear down to 2nd.

Re: Python 3.5.0

#92

Post by jay_kyburz »

rizwank wrote: post #58
redsymbol wrote: post #34

Python 3 keeps getting better and better. I've been writing more code in Python 3 than 2 for about three years now, and I absolutely love it. When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second.

Is Py3 ready for prime time? Do all the right libraries have support now?

Unfortunately I'm stuck on 2.7 until Google updates App Engine

Re: Python 3.5.0

#93

Post by foob »

rizwank wrote: post #58
redsymbol wrote: post #34

Python 3 keeps getting better and better. I've been writing more code in Python 3 than 2 for about three years now, and I absolutely love it. When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second.

Is Py3 ready for prime time? Do all the right libraries have support now?

In most cases, yes. There are libraries that you might want to use that don't support it yet but the vast majority do. Personally, I'm anxiously waiting for Fabric 2 which has been pending for a long time. This is a good resource for figuring out whether the libraries you need are ready: http://py3readiness.org

Re: Python 3.5.0

#94

Post by vegabook »

jcadam wrote: post #57

I'd love to use Python 3. Alas, I work in the defense industry and am working on a new development project in Python 2.6. Why? Because that's the version that's already installed on the client's systems, and getting anything new installed is such a nightmare of Vogon-esque policies and procedures that I've learned not to even ask. I'm constantly having to hack around bugs in ancient versions of libraries that have be…

I went to 3.3 a while ago but reverted back to 2.7 because out of the 10 or so crucial libraries I needed, one was still on 2.7. Bloomberg. (http://www.bloomberglabs.com/api/libraries/). That's what the people who talk about high percentages of libraries already ported to 3, miss. All you need is a single one not to be ported and the future stays on hold.

I have taken to using the 3 syntax in 2.7 so that I am prepared, but until this particular library moves, I cannot.

Re: Python 3.5.0

#96

Post by dalke »

Veedrac wrote: post #84
dalke wrote: post #22

Earlier quoted context omitted.

Other options for your first case are: >>> sum((range(i) for i in range(5)), []) [0, 0, 1, 0, 1, 2, 0, 1, 2, 3] and >>> import itertools >>> list(itertools.chain.from_iterable(range(i) for i in range(5))) [0, 0, 1, 0, 1, 2, 0, 1, 2, 3] "filter keeping the type". That was only true for some types. Python 2.7's filter does not maintain the set type: >>> filter(lambda x: x in 'ABC', {'A','B','C','D','E','F','A'}) ['A',…

> sum((range(i) for i in range(5)), []) This won't work in Python 3 since `range` is a new type (and it's O(n²) anyway, so not missed). The second option is idiomatic IMHO.

Indeed! I incorrectly thought I tested that under both versions. And I didn't notice the O() performance, which is:

    >>> for i in range(20):
    ...   t1 = time.time()
    ...   n = len(sum((list(range(i)) for i in range(2**i)), []))
    ...   t2 = time.time()
    ...   print(i, t2-t1)
    ... 
    0 0.00010800361633300781
    1 2.288818359375e-05
    2 2.5033950805664062e-05
    3 4.00543212890625e-05
    4 7.295608520507812e-05
    5 0.00017499923706054688
    6 0.0005929470062255859
    7 0.0024929046630859375
    8 0.012469053268432617
    9 0.14577507972717285
    10 1.7278220653533936
    11 17.82376503944397
    ^C
(MHO too, BTW.)

Re: Python 3.5.0

#98

Post by dalke »

iso8859-1 wrote: post #75
dalke wrote: post #15

Earlier quoted context omitted.

I want to see it used for an XML library, since I think node@"name" is a more succinct, and domain-appropriate equivalent for node.attrib.get("name").

Why not just use the array indexing operator for that?

In which way? node[1] means the second child.

If you mean node[x] returns node.attrib.get(x) when x is a string, and the nth-child when x is an integer, then I think that puts too much complexity into the API.

If you mean stay with the existing node.attrib dict-like API, then node@name is a simple shortcut for node.attrib.get(name), but it's 1) more aligned with CSS/XSL '@' notation for attribute syntax, and 2) faster in CPython.

(Just realized that '/' and '//' also make sense in that context. node / "abc" / "xyz" @ "p" would be the child "abc"'s child "xyz"'s attribute "p". Perhaps my proposal is a bad idea because it might suggest that these other forms are allowed.)

Re: Python 3.5.0

#99

Post by orf »

wfunction wrote: post #89
redsymbol wrote: post #34

Python 3 keeps getting better and better. I've been writing more code in Python 3 than 2 for about three years now, and I absolutely love it. When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second.

> When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second. You mean, second gear up to fifth? I tried writing some Python 3 code and the lack of parameter tuple unpacking by itself stunned me and drove me crazy, never mind other stuff. Python 3 seems very user-unfriendly compared to Python 2. Won't touch it with a ten foot pole unless my life depends on it.

I've been using Python for 7+ years, and I had no idea parameter tuple unpacking was a thing. Never once seen any code that uses it, or seen anyone mention it. If you think the (rightful) removal of a hardly used feature[1] that has some big problems is a blocking issue then I feel sorry for you. Py3 is awesome.

1. https://www.python.org/dev/peps/pep-3113/

Re: Python 3.5.0

#100

Post by zo1 »

ricw wrote: post #2

By far the most exciting news here, to me, is PEP 484 typing module. Typing support would eliminate one of pythons biggest weaknesses. Furthermore, having it optional means it can remain as easy play and prototype with while becoming "more professional." The other features are all well rounded, with co-routines having quite some potential, though I'd have to play around with them first to assess. Now if everything wo…

"Now if everything would please start moving on to Python 3 pretty please ;)."

Unfortunately, not always an option. Or rather, it is, but would require an immense amount of effort. Not to mention, the client wouldn't be too happy with the increase in bugs.

Working on a legacy C++/Python implementation stuck with 2.5. It's not as bad as it sounds, really. You learn to improvise, and work on python 2.7/3+ in off-hours.

Post reply on HN