On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico <ros...@gmail.com> wrote: > That'll make Python 2.6/2.7 behave like Python 3.x in three ways: > firstly, "print" will be a function instead of a statement (and it's > more powerful than the statement form, as well as being more > flexible); secondly, quoted strings will be Unicode strings, not byte > strings (that'll help you to start thinking about what's bytes and > what's text, which is an important distinction in Python 3); and > thirdly, though less important than the others, the division of two > integers will result in a floating point, not an integer. I personally > think the last one was a mistake on Python 3's part (why bless float > specifically? what if you're working with integers and > decimal.Decimals?), but if you're going to move to Python 3, you may > as well have your code start working that way, so you get used to > typing // to divide integers and get an integer (floor division).
If you're working with decimals, then the result is a decimal. If one side is an integer and the other is a decimal, then the result is still a decimal. Similarly if one of the operands is a fraction, then the result is a fraction. The change from / denoting "classic division" to "true division" really only affects the case where both operands are integers, so far as I'm aware. If you want to divide two integers and get a decimal result, then convert one or both of them to decimals first; you would have needed to do the same with classic division. We also gained a consistent and explicit way to differentiate between the two different styles of division that classic division represented, as opposed to picking at run-time based on type. As for "why float" specifically, the division __future__ import has been around since 2.2, longer than either decimals or fractions. -- https://mail.python.org/mailman/listinfo/python-list
