Python Mystery Theatre -- Episode 2: Así Fue

[John Machin]

Robin Becker <robin at jessikat.fsnet.co.uk> wrote in message news:<m4UoZJA308E$EwjN at jessikat.fsnet.co.uk>...
> In article <6qvfu4jgh1.fsf at salmakis.intevation.de>, Bernhard Herzog
> <bh at intevation.de> writes
> >"Raymond Hettinger" <vze4rx4y at verizon.net> writes:
> >
> >> [Jason Trowbridge]
> >> > Act I
> >> > I didn't know that python formatting could do that!  I've always
> >> > treated it like C's printf-style of statements, as that seems to be
> >> > what it's primarily based off.
> >> 
> >> That's why this one was included.
> >> Hope everyone learned something new.
> >
> >C's printf can do this too. At least the one in the GNU libc can. It's
> >docs don't say anything about this being a GNU extension so I guess it
> >can be found in other libcs as well, though probably not in all.
> >
> >   Bernhard
> >
> I know that it's in microsoft
> 
> the print width description contains
> 
> '''If the width specification is an asterisk (*), an int argument from
> the argument list supplies the value. The width argument must precede
> the value being formatted in the argument list. A nonexistent or small
> field width does not cause the truncation of a field; if the result of a
> conversion is wider than the field width, the field expands to contain
> the conversion result.'''

It's pretty much bog-standard C. E.g. K&R2, appendix B, section 1.2
says:
'''
Width or precision or both may be specified as *, in which case the
value is computed by converting the next argument(s), which must be
int.
'''

>>> "%+0*.*f" % (10,3,123.45678)
'+00123.457'

There you go, as advertised.