> I think you are mistaken.  Python always distinguished between floats
> and integers

Sorry, my bad.

> For example, if
> bin is used inside f()  only to  produce some log output,  but
> otherwise f() works on any number, promiscuous bin() will actually
> make an application using f() more robust.

First I'm not sure bizarre log output should be considered "more
robust". Second if you are outputting the bin() of an integer as part of
a log output, it probably means the integer should be understood as a
kind of bitfield, and then I don't see how accepting float values is
"more robust" (again). Anyway Python doesn't accept floats for bit-wise
operators (e.g. "1.0&128" raises TypeError).

I still find this proposal undesirable, for several reasons:

1. while taking the binary representation of an integer has a real
meaning, taking the binary representation of a float only exposes an
implementation detail, that is the internal layout of float numbers. 

2. if two numbers (one integer and one float) are equal, it sounds
expectable that calling a function on them will produce similar output
(or fail). Of course, this is not always the case, str(1) and str(1.0)
are different. But they are not wildly different and the difference is
still easily understood. While getting something like
'0b11.001001000011111101101010100010001000010110100011' while you were
waiting for '0b11' is disturbing.

3. I'm skeptical about the educational value. People who don't know
about the internal layout of float numbers won't very likely feel
enlightened by a string of 1s and 0s. Showing a bunch of bits does not
really explain a structure.

One related feature, though, would be to know whether a string
representation of a float is exact or not. 
If we allowed repr() to lose its round-trippability, this could be
implemented by making repr(0.5) return "0.5 (exact)" and repr(0.1)
return "0.10000000000000001 (inexact)".
Or this could be a dedicated method.


> While writing my previous comments I did not realize that '%x' %
> accepts floats:

And witness how it does something rather intuitive (convert the argument
to int) rather than show the internal layout of the float number in
hexadecimal form :-)