[Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

["Martin v. Löwis"]

> I think the above it still a bit easier to understand than
> if one has to figure out where the sign/exponent and
> exponent/fraction bit boundaries are, unbias the exponent,
> and add the extra hidden '1' bit into the mantissa.  That's
> a lot of mental work.

Sure. However, I'd argue that most people are unable to even
remotely guess the number in decimal when presented with the
number in hexadecimal - at a minimum, they'll fail to recognize
that the exponent is not to the power of 10, or when they
realize that, might guess that it is to the power of 16
(I find it fairly confusing, but consequential, that it is
to the power of 2, even when the digits are hex - and then,
the exponent is decimal :-).

So I'd like to dismiss any objective of "the output must be
human-understandable" as unrealistic. That an unambiguous
representation is desired, I can understand - but only if there
also is a way to enter the same representation elsewhere.

In addition, I fail to see the point in binary representation.
For unambiguous representation, it's sufficient to use hex.
I can't accept claims that people will be actually able to
understand what number is represented when given the bit string.
For educational purposes, decoding mantissa and biased exponent
directly out of the IEEE representation is better than having
binary output builtin.

>     Also, to follow C's tradition, it would be better if that was
>     *not* integrated into the hex function (or a hex method), but
>     if there was support for %a in string formatting.
> 
> 
> I'd be delighted with '%a' support.

I personally find that much less problematic than extending the
hex, and wouldn't object to a patch providing such formatting
(assuming it does the same thing that C99 printf does).

Regards,
Martin