from __future__ import division is returning int instead of float in python 2

[euresti]

I noticed this when mypy --py2 worked but mypy for python 3 failed.

from __future__ import division
x = 2 / 3
reveal_type(x)  # This returns int

[gnprice]

Thanks for reporting this!

In fact, on some debugging, there appears to be a TODO in the code for just this issue:
https://github.com/python/mypy/blob/897398eff/mypy/checkexpr.py#L1010

Currently we read future-options in the parser (storing them on the future_options attribute), and parser code consults self.future_options for the print_function and unicode_literals options. Then we forget them -- so they're not readily available where this TODO comment appears, in the type-checker.

Probably we should record the future-options on the MypyFile data structure which the parser records to describe the module. Then we could check them in places like where this TODO comment appears.

[Michael0x2a]

Raising priority to normal, as requested here.

Something else to keep in mind is that it seems like mypy just doesn't handle division in Python 2 very gracefully in general.

In particular, whoever decides to tackle this issue also ought to carefully audit any code that calls
node.op_methods and the following data structures.

Many (but not all) of those data structures do not include __div__ to support the Python 3 use case and patch over this to support Python 2 somewhat inconsistently. (For example, see the get_operator_method linked above).

The net effect is that our codebase sometimes handles __div__ correctly and sometimes doesn't. For example, up until very recently, our code simply didn't check for unsafe overlaps between __div__ and __rdiv__.

Another example of an inconsistency: the error message you get when doing x / y when __div__ is missing is different then the error message you get when doing x + y when __add__ is missing.

[hauntsaninja]

What is Python 2?