[Python-Dev] str with base (original) (raw)

Bob Ippolito bob at redivi.com
Wed Jan 18 04:30:10 CET 2006

On Jan 17, 2006, at 7:12 PM, Jack Diederich wrote:

On Tue, Jan 17, 2006 at 06:11:36PM -0800, Bob Ippolito wrote:

On Jan 17, 2006, at 5:01 PM, Jack Diederich wrote:

On Tue, Jan 17, 2006 at 04:02:43PM -0800, Guido van Rossum wrote: On 1/17/06, Adam Olsen <rhamph at gmail.com> wrote:

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. Has this been proposed? What would %b print? It was proposed in this or another thread about the same in the last few days (gmane search doesn't like the % in '%b'). The suggestion is to add 'b' as a sprintf-like format string %[][.]b Where the optional is the base to print in and is the optional minimum length of chars to print (as I recall). Default is base 2. Me? I like it. Personally I would prefer the "b" format code to behave similarly to "o", "d", and "d", except for binary instead of octal, decimal, and hexadecimal. Something that needs to account for three factors (zero pad, space pad, base) should probably be a function (maybe a builtin). Hell, maybe it could take a fourth argument to specify how a negative number should be printed (e.g. a number of bits to use for the 2's complement). However... if %b were to represent arbitrary bases, I think that's backwards. It should be %[][.]b, which would do this: >>> '%08b %08o %08d %08x' % 12 '00001100 00000014 00000012 0000000C' Were I BDFAD (not to be confused with BD-FOAD) I'd add %b, %B and, binary() to match %x, %X, and hex(). The arbitrary base case isn't even academic or we would see homework questions about it on c.l.py. No one asks about hex or octal because they are there. No one asks about base seven formatting because everyone knows numerologists prefer Perl.

There shouldn't be a %B for the same reason there isn't an %O or %D
-- they're all just digits, so there's not a need for an uppercase
variant.

The difference between hex() and oct() and the proposed binary() is
that hex() and oct() return valid Python expressions in that base.
In order for it to make sense, Python would need to grow some syntax.

If Python were to have syntax for binary literals, I'd propose a
trailing b: "1100b". It would be convenient at times to represent
bit flags, but I'm not sure it's worth the syntax change.

binarydigit ::= ("0" | "1") binaryinteger ::= binarydigit+ "b" integer ::= decimalinteger | octinteger | hexinteger | binaryinteger

-bob

More information about the Python-Dev mailing list