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

Python 2 vs. Python 3: A retrospective

dropbox.com

Post reply on HN
Print view View original

81–90 of 113 posts

Re: Python 2 vs. Python 3: A retrospective

#81

Post by anonymous »

jzwinck wrote: post #48
justinmk wrote: post #35

I'd really like to see the video for these slides. But here's what caught my interest: Set and dict comprehensions {x**2 for x in range(10)} {x: x**2 for x in range(10)} Why reduce() must die: ... the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly. int [divided by] int should return float nonlocal Explicit non…

You know what's funny? All of those things could have been done in Python 2.8, apart from the int division change. And the division change does as much harm as good, because lots of people use Python and also use another language where int division works the "old fashioned way"; for them (me) this change is counter-productive because it adds a pointless distinction. It is a great change for programming novices, for s…

All of these things, including the int division "thing" are present in python 2.7 already. For division, you need to import it:

    from __future__ import division
And then dividing numbers works a bit more logical (well I think it's more logical). You can do division with rounding with the // operator: a // b, and it even works with floats: (3.9 // 1.2) == 3

Re: Python 2 vs. Python 3: A retrospective

#82

Post by dagss »

TylerE wrote: post #62
yen223 wrote: post #57

Earlier quoted context omitted.

The division change is good. I have a hard time understanding why you'd want 3/2 = 1 as the default behaviour.

Imagine the following (admittedly bad, minimalistic to make my point) code x = int(input(">>> ")) a = x / 2 append_int_to_magical_db(a) If the division does a "naturaL" thing, you suddenly have a float "polluting" your integer algorithm, but it's _not consistent_. If the user enters "4", you get an int back. If they enter 5, you get a float.

a = x // 2

Re: Python 2 vs. Python 3: A retrospective

#83

Post by nhaehnle »

meowface wrote: post #77
TylerE wrote: post #62

Earlier quoted context omitted.

Imagine the following (admittedly bad, minimalistic to make my point) code x = int(input(">>> ")) a = x / 2 append_int_to_magical_db(a) If the division does a "naturaL" thing, you suddenly have a float "polluting" your integer algorithm, but it's _not consistent_. If the user enters "4", you get an int back. If they enter 5, you get a float.

Users of Python 3 and up will just have to remember that the result of any division will be a float. It's a breaking change, yes, but in general I think it's a good one.

And if they do want integer division, they have to remember // and %.

Re: Python 2 vs. Python 3: A retrospective

#84

Post by unfamiliar »

jzwinck wrote: post #48
justinmk wrote: post #35

I'd really like to see the video for these slides. But here's what caught my interest: Set and dict comprehensions {x**2 for x in range(10)} {x: x**2 for x in range(10)} Why reduce() must die: ... the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly. int [divided by] int should return float nonlocal Explicit non…

You know what's funny? All of those things could have been done in Python 2.8, apart from the int division change. And the division change does as much harm as good, because lots of people use Python and also use another language where int division works the "old fashioned way"; for them (me) this change is counter-productive because it adds a pointless distinction. It is a great change for programming novices, for s…

I have tracked down many confounding bugs caused by people accidentally using integer division. This change is one of the main reasons I use python 3; it gives me one less thing to worry about, because integer division (which is only correct occasionally) stands out clearly with //.

Re: Python 2 vs. Python 3: A retrospective

#85

Post by pjmlp »

steveklabnik wrote: post #53
andyl wrote: post #42

It seems like I've been reading about the difficulties of Python V2 -> V3 for awhile. Why is that? Is this Python upgrade unusually difficult/ambitious? Or is the Python community just very reluctant to jump on new things?

In Ruby world, some people are still on 1.8.7, even though it was end-of-life'd in June, and it was known that it would be on that date a few years before. Change is hard. People don't want to spend the money on upgrading. It's almost all downside with very little upside.

Around January this year, my employer was still getting requests for Java 1.4!

Don't ever upgrade a running system until you are forced to do so.

Re: Python 2 vs. Python 3: A retrospective

#86

Post by aidos »

yeukhon wrote: post #30
aidos wrote: post #20

Earlier quoted context omitted.

That's totally against the ethos of python. I think you'll find that very few python developers would side with you on that change. If I'm iterating over something I'd like the elements of the thing I'm iterating over, not some weird results based on the type of iterator. In the (extremely) rare cases I need an index I wrap the list/whatever in the enumerate function. What are the use cases where you frequently need…

Whoever downvoted me have some weird negativity here. It doesn't against ethos of Python. There is a Zens of Python, I don't know Ethos of Python. http://www.python.org/dev/peps/pep-0020/ Beautiful is better than ugly. Writing .items() or surrounding enumerate() does not make your code look prettier, does it? Explicit is better than implicit. In fact, my proposal is more explicit than the implicit of for key in my_di…

I didn't downvote you, but I feel I should. You're suggesting making a magical change to a language because you seem to have failed to grasp the way it works.

If the best use case you can come up with is the one you've given then we've got real issues. If my team were ever iterating over a list to find the index of an item I would be very upset. That is categorically not the right way to do it.

Regarding the ethos - zen, ethos, call it what you will. Explicit is better. Maybe English isn't your first language but your idea is less explicit than the way it works T te moment.

Re: Python 2 vs. Python 3: A retrospective

#87

Post by masklinn »

jzwinck wrote: post #48
justinmk wrote: post #35

I'd really like to see the video for these slides. But here's what caught my interest: Set and dict comprehensions {x**2 for x in range(10)} {x: x**2 for x in range(10)} Why reduce() must die: ... the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly. int [divided by] int should return float nonlocal Explicit non…

You know what's funny? All of those things could have been done in Python 2.8, apart from the int division change. And the division change does as much harm as good, because lots of people use Python and also use another language where int division works the "old fashioned way"; for them (me) this change is counter-productive because it adds a pointless distinction. It is a great change for programming novices, for s…

> All of those things could have been done in Python 2.8

The first one is in 2.7 (it's completely backwards compatible). The division is in 2.5 or 2.6 imported from __future__. #4 skirts the line, new keywords have been added in point release in the past. #2 wouldn't fly.

But here's the thing, P3 was not about these (or not only about them), they got bundled in because P3 was allowed to be significantly backwards-incompatible and thus a lot of changes became acceptable which were not justifiable or much harder to justify in a point release. The primary breakage point of P3 is not any of these, it's the string changes.

Re: Python 2 vs. Python 3: A retrospective

#88

Post by masklinn »

TylerE wrote: post #62
yen223 wrote: post #57

Earlier quoted context omitted.

The division change is good. I have a hard time understanding why you'd want 3/2 = 1 as the default behaviour.

Imagine the following (admittedly bad, minimalistic to make my point) code x = int(input(">>> ")) a = x / 2 append_int_to_magical_db(a) If the division does a "naturaL" thing, you suddenly have a float "polluting" your integer algorithm, but it's _not consistent_. If the user enters "4", you get an int back. If they enter 5, you get a float.

It's bad and it does not make your point. In P2 you always get an int, in P3 you always get a float.

Re: Python 2 vs. Python 3: A retrospective

#89

Post by masklinn »

steveklabnik wrote: post #56
spamizbad wrote: post #36

Earlier quoted context omitted.

The Python ecosystem is far too diversified to get knocked down by one language. Python has a wealth of production-quality libraries across a ton of domains (Web, scientific computing, data science, NLP, parsing, scripting/automating, etc). Go is a non-entity in most of these domains and isn't even a top-20 programming language on Github (source: http://sogrady-media.redmonk.com/sogrady/files/2013/07/progr... ) Pytho…

The scientific Python community will never leave 2.5 -> 2.7, though...

Half the core scientific packages are already P3-compatible. Numpy has supported P3 since 2010[0] and scipy since early 2011[0][1]

[0] http://sourceforge.net/projects/numpy/files//NumPy/1.5.0/NOT... https://pypi.python.org/pypi/numpy/1.5.0

[1] http://docs.scipy.org/doc/scipy-0.9.0/reference/release.0.9....

Re: Python 2 vs. Python 3: A retrospective

#90

Post by masklinn »

ajford wrote: post #72
steveklabnik wrote: post #56

Earlier quoted context omitted.

The scientific Python community will never leave 2.5 -> 2.7, though...

The science community will get there. The problem is that for a long time, NumPy/SciPy/etc. didn't support 3.x. And when you're more interested in end results, why would you rewrite your code (or spend days/weeks/months relearning) when you could use a still perfectly acceptable and supported version? There's also a lot of reuse and expansion on existing code bases, which would involve a lot of work to migrate to 3.x…

> The science community will get there. The problem is that for a long time, NumPy/SciPy/etc. didn't support 3.x.

They were some of the earliest ported widely-used packages. Numpy was ported in 2010, scipy very early in 2011 (except for weave iirc)

Post reply on HN