[jimmaswell]

Python3's treatment of integer literals in that case is bad. The first is the behavior that someone used to programming will expect by default, since those are integers. If you want non-integer operations you should have to use a decimal point in the 1 or 2.

[BoppreH]

I disagree. A strong type system is good, but in this case pragmatism wins the battle. I personally have been bitten innumerous times by bugs where division was rounded down (usually to 0, which is especially destructive).

Most of the numbers I encounter start as integers and most of the calculations I need are floating-point. This language behavior saves me from sprinkling "* 1.0" everywhere on my code, or from introducing extremely subtle bugs.

And the integer division is always there, one character away:

    print(1//2 * 1000)   # 0

[jimmaswell]

I just think it's nuts that we're upcasting ints to floats implicitly. Explicitness over implicitness is one of Python's guidelines.

[BoppreH]

Python3's '/' operator is different from Python2's '/' operator. This is clear when you try to overload them. Python2's is called '__div__', while Python3's is '__truediv__'.

The Python3's operator '/' (on numbers) is defined to return a float, and it'll convert any integer parameters as required. The same is true for other operators, like 'True + True' being 2.

Because of these definitions, you should consider the operators as explicit conversions. 'total / sum' is less explicit than 'total / float(sum)', but still clear enough.

And about guidelines, there are others that fit this case:

    Simple is better than complex.
    Flat is better than nested.
    Readability counts.
    [...] practicality beats purity.
    

PS: I think you made an important argument and I'm glad you did it, even though I disagree with it. I fail to see why you are getting downvotes.

[jimmaswell]

I guess I don't mind it that much.

I went to check out the operation and it seems a on two ints returns an int if the power is a nonnegative int, and a float if it's negative nonzero, in both 2.7 and 3. I didn't expect this kind of inconsistency from python, really.

    >>> type(2 ** 1)
    <type 'int'>
    >>> type(2 ** -1)
    <type 'float'>

I guess it does follow the last line of the guidelines there, though. Looking at this power example, the division returning float now is actually an increase in consistency.

[andreasvc]

I think it's better to think of it as division being an operation that returns the appropriate type for the operation, i.e., a float where necessary. The type of the operands remain unchanged so "upcasting" is not applicable if you ask me.

[collyw]

Looking at that example, the second one looks more correct to me without thinking about it too much.

But if I was writing it I would space the "1/2" into "1 / 2".

The first says half to me (ok, until I pause and realise it is code I am interpreting), while the second is 1 divided by 2.

[heinrich5991]

The good thing is that you can get that behavior if you really intend it, just use the // operator. I'm really in favor of this change.

[mark-r]

Even better is that // has been available in Python 2 for ages, so you can get used to using it everywhere. Evidently they were anticipating this change.