A division which results in int, does not produce int ?!?

Here is the test case.

from __future__ import division
assert(isinstance(2 / 1, int))

This is by design. Having different result types based on the input
values would not be "smart" in my book, rather "incredibly fragile".

> Having different result types based on the input
> values would not be "smart" in my book, rather "incredibly fragile".

Well, there are precedents:

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

My initial reaction to this was negative, but I'm struggling to think of 
situations where it would be bad.  I'm also struggling to think of 
situations where it would be useful.   Maybe Monday morning is just a 
bad time for thinking. :-)

Might be worth a discussion on python-ideas, at least?

To the OP:  you should be aware that getting this accepted into Python 
would likely be very hard.  You'd need at least a PEP explaining clearly 
the benefits of such a change, a working patch, and strong community 
support.  And even then it might have to wait for Python 4.0.  Which 
Guido has said probably won't happen...

On Mon, Dec 1, 2008 at 7:15 AM, Mark Dickinson <report@bugs.python.org> wrote:
> Well, there are precedents:
>
>>>> type(2**3)
> <type 'int'>
>>>> type(2**-3)
> <type 'float'>
>
> My initial reaction to this was negative, but I'm struggling to think of
> situations where it would be bad.  I'm also struggling to think of
> situations where it would be useful.   Maybe Monday morning is just a
> bad time for thinking. :-)
>
> Might be worth a discussion on python-ideas, at least?

I don't know about the internal representations in python, but I
believe ints can be larger than ints. Nevertheless your example there
which would have drove me nuts if I found it :-). I like the true
division feature, but I find it too far deviant, if all of a sudden
code started producing floats instead of ints, on a given upgrade of
python someday soon.

I think the result should be int if it is an int, but float if and
only if it is really needed.

I think your right, this conversation should probably move to python
ideas, since this was by design and not a bug. (but I do not really
like this part of the "feature").

On Mon, Dec 1, 2008 at 7:43 AM, Hatem Nassrat <hnassrat@gmail.com> wrote:
> On Mon, Dec 1, 2008 at 7:15 AM, Mark Dickinson <report@bugs.python.org> wrote:
>> Well, there are precedents:
>>
>>>>> type(2**3)
>> <type 'int'>
>>>>> type(2**-3)
>> <type 'float'>
>>
>> My initial reaction to this was negative, but I'm struggling to think of
>> situations where it would be bad.  I'm also struggling to think of
>> situations where it would be useful.   Maybe Monday morning is just a
>> bad time for thinking. :-)

It seems to not be my day either. I think the above behaviour is what
I would expect.

Le lundi 01 décembre 2008 à 11:15 +0000, Mark Dickinson a écrit :
> My initial reaction to this was negative, but I'm struggling to think of 
> situations where it would be bad.

Consider someone who writes:

z = y / x
return my_list[z]

In all his tests, x is a divisor of y and therefore z is an integer, the
code runs ok.
Suddenly in an use case, x is not a divisor of y, z is therefore a
float, and the "return" line raises a TypeError.

The reverse can also happen, consider something like :

z = y / x
return z.as_integer_ratio()

As for :

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

I'd argue it is less annoying because it only depends on the value of
the second operand which is, most of the time, a constant, and therefore
you know upfront if the result will be a float or an int.

On Mon, Dec 1, 2008 at 8:01 AM, Antoine Pitrou <report@bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> Le lundi 01 décembre 2008 à 11:15 +0000, Mark Dickinson a écrit :
>> My initial reaction to this was negative, but I'm struggling to think of
>> situations where it would be bad.
>
> Consider someone who writes:
>
> z = y / x
> return my_list[z]
>
> In all his tests, x is a divisor of y and therefore z is an integer, the
> code runs ok.
> Suddenly in an use case, x is not a divisor of y, z is therefore a
> float, and the "return" line raises a TypeError.

That brings me to another point which will make you guys think i'm
crazy and close this thread immediately :-). I actually tried that
recently (that being using a float as an index), actually used it as a
slice. I would think that should work, it should round the float
usually, and if used in a slice, if it is an end it should round up,
if it is a start round down, for 0.5?

Maybe I should write my first PEP and watch it thrown out :-)