Hacker News Reader

Comment by ufo | Hacker News Reader

The integer division is more surprising in a dynamic language because it might stay undetected until the day you happen to pass round numbers to your function.

View on HN

I don't think you're correct. If you, the designer, made those operands, you should expect them to be int() or float() because of how you created them. int() and float() have lots of other differences beyond just how they're treated by division.

In my experience, at some point someone will write f(x, 2) instead of f(x, 2.0). This especially happens when you are trying to debug something at the REPL. The addition of the // operator has really solved the problem and given us the best of both worlds here.

The SymPy author was explicitly talking about users. The sort of folks that use matlab, mathematica, and maple.

I don't know of any of them that expect 2 / 3 to be an integer.

And as ufo says, it creates subtle bugs because it works right on most data until you just happen to get a pair of ints. Then boom.

eg in Matlab all numbers are doubles unless you take action to make them otherwise.

Having a function/operator return different results depending on the type seems a bit insane, from a non-C/Python perspective.

> There should be one-- and preferably only one --obvious way to do it.

If I divide 1 in half, I'm left with 0.5.

There's a better way.

    (/ 2 3)   ; => 2/3
    (/ 2.0 3) ; => 0.6666667

"you, the designer" may not have created the operands, just taken them as function arguments. Sure, you should have written tests for different types of input, but if you didn't, it may surprise you later.

Reply on news.ycombinator.com