homepage

>>> (78*6e-8) / 6e-8
78.0
>>> (78*6e-8) // 6e-8
77.0
Note this doesn't make divmod() wrong:
>>> q, r = divmod(78*6e-8, 6e-8)
>>> q, r
(77.0, 5.999999999999965e-08)
>>> r < 6e-8
True
>>> q * 6e-8 + r == 78*6e-8
True
But, still, it is somewhat of an oddity to not return the real quotient when it is an exact integer.
Note this came from a Numpy issue where Numpy actually shows better behaviour:
https://github.com/numpy/numpy/issues/6127 

Stare at footnote 2 for the Reference Manual's "Binary arithmetic operations" section:
"""
[2] If x is very close to an exact integer multiple of y, it’s possible for x//y to be one larger than (x-x%y)//y due to rounding. In such cases, Python returns the latter result, in order to preserve that divmod(x,y)[0] * y + x % y be very close to x.
"""
This is such a case.
>>> x
4.679999999999999e-06
>>> y
6e-08
>>> divmod(x,y)[0] * y + x % y == x
True
>>> (x/y) * y + x % y == x
False
>>> ((x/y) * y + x % y) / x # and not close at all
1.0128205128205128
Yes, trying to preserve identities in floating-point always was a fool's errand ;-)
Note that "but x is an _exact_ integer multiple of y, not just 'very close to'" would be succumbing to an illusion:
>>> dx = decimal.Decimal(x)
>>> dy = decimal.Decimal(y)
>>> dx / dy
Decimal('77.99999999999999426488108630')
It's just that x/y _appears_ to be an exact integer (78) due to rounding. As the decimal calcs show, infinite-precision floor division really would return 77.

Hum, I see. What is the rounding mode used by true division, by the way?

IEEE 754 uses the ROUND_HALF_EVEN rounding mode by default:
https://en.wikipedia.org/wiki/Rounding#Round_half_to_even
That's why round() uses the same rounding mode. I discovered recently while working on the datetime module :-) (issue #23517)

> What is the rounding mode used by true division,
For binary floats? It inherits whatever the platform C's x/y double division uses. Should be nearest/even on "almost all" platforms now, unless the user fiddles with their FPU's rounding flags.

BTW, I find this very hard to understand:
"it’s possible for x//y to be one larger than" ...
This footnote was written long before "//" was defined for floats. IIRC, the original version must have said something like:
"it's possible for floor(x/y) to be one larger than" ...
instead. Which does make sense ... yup, the old docs were actually coherent here ;-)
https://docs.python.org/release/2.1/ref/binary.html 

I agree with Tim that this is the correct behaviour. Antoine: okay to close? Or should we leave it open for the doc fix that Tim noticed?

>>> from fractions import Fraction
>>> Fraction(78*6e-8) / Fraction(6e-8)
Fraction(353610802237278976, 4533471823554859)
>>> Fraction(78*6e-8) // Fraction(6e-8)
77
>>> float(Fraction(78*6e-8) / Fraction(6e-8))
78.0
>>> Fraction(78*6e-8) / Fraction(6e-8) - 78
Fraction(-26, 4533471823554859)
The root of the issue is that
>>> Fraction(78*6e-8) != Fraction(78*6, 10**8)
True
>>> Fraction(6e-8) != Fraction(6, 10**8)
True

I have no problem with closing. Admittedly, I opened this issue mostly to get a witty and enlightening response :-)

"""
The root of the issue is that
>>> Fraction(78*6e-8) != Fraction(78*6, 10**8)
True
>>> Fraction(6e-8) != Fraction(6, 10**8)
True
"""
It's not an issue, it's just a fact: floating point rounding is annoying and very few people understand it :-)

> What is the rounding mode used by true division, by the way?
Probably not what you were asking, but with respect to true division of integers (int / int -> float), we always use round-half-to-even. Any deviation from that (non-IEEE 754 platforms excepted) is a bug that should be reported.