On Tue, 2006-01-17 at 16:38 -0700, Adam Olsen wrote:
On 1/17/06, Thomas Wouters thomas@xs4all.net wrote:
On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote:
[...]
I dream of a day when str(3.25, base=2) == '11.01'. That is the number a float really represents. It would be so much easier to understand why floats behave the way they do if it were possible to print them in binary.
[...]
Heh... that's pretty much why I used base16 float notation when doing fixed point stuff in assembler... uses less digits than binary, but easily visualised as bits.
However, I do think that we could go overboard here... I don't know that we really need arbitrary base string formatting for all numeric types. I think this is a case of "very little gained for too much added complexity".
If we really do, and someone is prepared to implement it, then I think adding "@base" is the best way to do it (see my half joking post earlier).
If we only want arbitrary bases for integer types, the best way would be to leverage off the existing ".precision" so that it means ".base" for "%d".
In-favour-of-%2b-ly y'rs,
My only opposition to this is that the byte type may want to use it. I'd rather wait until byte is fully defined, implemented, and released in a python version before that option is taken away.
There's always "B" for bytes and "b" for bits... though I can't imagine why byte would need it's own conversion type.
I'm not entirely sure everyone is on the same page for "%b" here... it would only be a shorthand for "binary" in the same way that "%x" is for "hexidecimal". It would not support arbitrary bases, and thus "%2b" would mean a binary string with minimum length of 2 characters.