Hacker News Reader

Comment by jzwinck | Hacker News Reader

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 sure, but that's only part of Python's audience, and probably won't be the longest-lived part.

View on HN

> another language where int division works the "old fashioned way"; for them (me) this change is counter-productive ... It is a great change for programming novices

Douglas Crockford made a point in a recent interview[1] (not the first time, I'm sure) that this is exactly the wrong reason to keep doing things "the way it's always been". Other examples he mentions: line endings (CR/LF), integer overflow, short vs long. Big vs little endian would be another obvious example.

Fred Brooks (Mythical Man Month) calls this "accidental complexity".

> [novices are] only part of Python's audience, and probably won't be the longest-lived part

By definition. But, it's not really a good use of anyone's time to be dealing with truncation in a time when it no longer has any reason to be the default except historical accident.

[1] http://hanselminutes.com/396/bugs-considered-harmful-with-do...

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

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

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

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.

> If the user enters "4", you get an int back.

No, it always returns a float in Python 3. 4/2 gives 2.0.

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

a = x // 2

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

Reply on news.ycombinator.com