%a format

[John Lenton]

Is there any reason python's printf-style formatting is missing the
(C99) '%a' specifier?

I'm sorry if this has been asked and answered before; I can't find it
on google ('%a' is a very awkward thing to look for):

--
John Lenton ([email protected]) -- Random fortune:
Los cementerios están llenos de valientes.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD4DBQFBPf4FgPqu395ykGsRAundAJY6K3b3hoSl0Of1r6KYpH4jYtYvAJ99KydK
2TNjiXJFj+rtikhRu0c9DA==
=T89S
-----END PGP SIGNATURE-----

 

[Tor Iver Wilhelmsen]

Is there any reason python's printf-style formatting is missing the
(C99) '%a' specifier?

Because it's not very well known or used? A google for "C printf
format string" gave lots of resources, none of which had %a.

Java's JDK 1.5 java.util.Formatter class supports it, though.

 

[Erik Max Francis]

Because it's not very well known or used? A google for "C printf
format string" gave lots of resources, none of which had %a.

It's not C99, anyway; my copy of C99 makes no mention of it (the only
mention of %a is associated with gmtime.

 

[John Lenton]

It's not C99, anyway; my copy of C99 makes no mention of it (the only
mention of %a is associated with gmtime.

hmm! weird. From printf(3):

a,A (C99; not in SUSv2) For a conversion, the double
argument is converted to hexadecimal notation (using the
letters abcdef) in the style [â€]0xh.hhhhp±d; for A
conversion the prefix 0X, the letters ABCDEF, and the
exponent separator P is used. There is one hexadecimal
digit before the decimal point, and the number of digits
after it is equal to the precision. The default
precision suffices for an exact representation of the
value if an exact representation in base 2 exists and
otherwise is sufficiently large to distinguish values of
type double. The digit before the decimal point is
unspecified for nonâ€normalized numbers, and nonzero but
otherwise unspecified for normalized numbers.

and looking at ISO/IEC 9899:1999 (E), it's on page 278, §7.19.6.1:


a,A

A double argument representing a floating-point number is
converted in the style [-]0xh.hhhh p±d, where there is one
hexadecimal digit (which is nonzero if the argument is a
normalized floating-point number and is otherwise unspecified)
before the decimal-point character235) and the number of
hexadecimal digits after it is equal to the precision; if the
precision is missing and FLT_RADIX is a power of 2, then the
precision is sufficient for an exact representation of the value;
if the precision is missing and FLT_RADIX is not a power of 2,
then the precision is sufficient to distinguish236) values of type
double, except that trailing zeros may be omitted; if the
precision is zero and the # flag is not specified, no decimalpoint
character appears. The letters abcdef are used for a conversion
and the letters ABCDEF for A conversion. The A conversion
specifier produces a number with X and P instead of x and p. The
exponent always contains at least one digit, and only as many more
digits as necessary to represent the decimal exponent of 2. If the
value is zero, the exponent is zero.

A double argument representing an infinity or NaN is converted in
the style of an f or F conversion specifier.


--
John Lenton ([email protected]) -- Random fortune:
It seems intuitively obvious to me, which means that it might be wrong.
-- Chris Torek

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBPifjgPqu395ykGsRAiC9AKDHxzMZlIBagfhfd8x47MjMHQYjkwCeIeYY
Sb9juru++yV4/Oc0cAmyvus=
=DrCR
-----END PGP SIGNATURE-----

 

[Erik Max Francis]

and looking at ISO/IEC 9899:1999 (E), it's on page 278, §7.19.6.1:

My bad, I did an incomplete search. Sorry about that.

 

[Dan Bishop]

Because it's not very well known or used? A google for "C printf
format string" gave lots of resources, none of which had %a.

They do if you search for "C99" instead of just "C".

Anyhow, another reason for not supporting "%a" is that it would be
redundant. It would be sufficent to define an "%x" format for floats.

 

[John Lenton]

They do if you search for "C99" instead of just "C".

Anyhow, another reason for not supporting "%a" is that it would be
redundant. It would be sufficent to define an "%x" format for floats.

I don't think that's a good idea: no other specifier is dual
integer/float, and you'd break code that passes floats to a %x
expecting it to work as a %u, but in hex.

Actually the answer I was expecting was "FooOS doesn't support it" or
somesuch, not 'uhhh... el qué?' %a is very useful for what it was
created: serializing floats without loss of precision, and I was
surprised that python didn't support it.

--
John Lenton ([email protected]) -- Random fortune:
De los parientes y el sol, entre más lejos, mejor.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBPlB0gPqu395ykGsRAkbNAJ9uBHuwo7xzm45LtGuFnIknTsl5bQCfdQO8
Xlr3B9uOJglR8D74sfTJt8I=
=/+Dw
-----END PGP SIGNATURE-----

 

[John Roth]

Because it's not very well known or used? A google for "C printf
format string" gave lots of resources, none of which had %a.

Java's JDK 1.5 java.util.Formatter class supports it, though.

I suspect there's no major reason more significant than that
no one has written the patch to support it. That might suggest
that no one really cares enough to do so - IIRC, Python
shifted from using the C library printf() function to its own
code some time ago, so there's no real commitment to
following the C standard in this instance.

If the OP wants it, I would suggest that he write the patch
(complete with the doc changes, etc.) and submit it. It might
be a good idea to provide a use case more significant than
"it's in the C99 standard" as well - but then I'm not
channeling the core developers that well these days.

John Roth

 

[Dan Bishop]

I suspect there's no major reason more significant than that
no one has written the patch to support it. That might suggest
that no one really cares enough to do so - IIRC, Python
shifted from using the C library printf() function to its own
code some time ago, so there's no real commitment to
following the C standard in this instance.

If the OP wants it, I would suggest that he write the patch
(complete with the doc changes, etc.) and submit it. It might
be a good idea to provide a use case more significant than
"it's in the C99 standard" as well - but then I'm not
channeling the core developers that well these days.

Why stick to just adding one conversion specifier to one data type?
Why not allow a programmer to define their own custom specifiers?

class Bits(int):
def __sprintf__(self, flags, precision, conversion):
if conversion == 'b':
# return a binary string
return itoa(self, 2) # Why isn't this a standard function?
else:
return NotImplemented
100

You'd be able to redefine the existing conversion too, in case you
want, for example, a high-precision numeric type to convert
'%.1000f'%x accurately.

 

[Steven Bethard]

class Bits(int):

def __sprintf__(self, flags, precision, conversion):
if conversion == 'b':
# return a binary string
return itoa(self, 2) # Why isn't this a standard function?
else:
return NotImplemented

Well, I'm guessing itoa isn't a standard function because it's not that
commonly used... Not that I'm claiming to have written the widest variety of
Python code, but I've never needed it.

It is available though through a relatively short sequence of builtins though:
.... return str(int(str(i), base))
....'4'

A little roundabout, but it does do the trick.

Steve

 

[Steven Bethard]

... return str(int(str(i), base))
...

Oops. My bad. You wanted the inverse. Just ignore me.

 

[Erik Max Francis]

Well, I'm guessing itoa isn't a standard function because it's not
that
commonly used...

It was a common library add-on in the DOS world, but it was never
standard.