On Fri, May 30, 2008 at 10:52 AM, Antoine Pitrou <report@bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> Well it's quite simple. Imagine you have a function f() which takes an
> integer parameter named x, and somewhere applies bin() to this parameters.

This is too abstract.  Depending on what f() is designed to do,
accepting floats may  or may not be the right thing.  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.
>
>
> Right now, if you call f(1.0) instead of f(1), you will get a TypeError,
> which is easy to detect: you then fix the call to f(1), and bin()
> produces the expected result ('0b1').

There is no "right now".  Builtin bin is new in 2.6.
>
> ..
>
> There is a reason Python recently introduced a stronger distinction
> between ints and floats (for instance the __index__ method, which bin()
> seems to use currently), I don't see the logic behind trying to undo it.

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

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: list indices must be integers
>>> int.__index__
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: type object 'int' has no attribute '__index__'

__index__ was introduced in order to allow user-defined class
instances to be used as indices without affecting the way floats are
treated.
>
>
> And it's not like printing the bin() representation of a float has any
> actually use (besides education, but education can use its own tools
> rather than builtin functions).

That's exactly my point.  Builtin bin being new, I cannot comment on
its actual use, but I've only used hex() in interactive sessions as an
easy to type alternative to the finger-twisting "0x%x" % incantation.
(IMO, "{0:b}".format(..) is even worse.)  In the scripts, however, you
would rarely need to create a string representation of single  number.
 More often you will need to embed a number in a larger message and
thus you will use % or str.format instead of bin/hex/oct anyways.

BTW, google code search quickly revealed the following antipattern:

   log.msg("real checksum: %s"%hex(hdr[19]))

(twisted-Zope-3.2.2/twisted/words/protocols/toc.py)

Surely "real checksum: %x" % hdr[19] would be a better choice.  (The
0x prefix generated by hex is just noise in the log output.)