[Python-Dev] Format factories (was Re: sWAPcASE Was: transform() and untransform() methods, and the codec registry)

[Jeffrey Yasskin]

On Sat, Dec 11, 2010 at 11:21 AM, Brett Cannon <brett at python.org> wrote:
> On Thu, Dec 9, 2010 at 16:26, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Fri, Dec 10, 2010 at 9:29 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> On Thu, 09 Dec 2010 18:10:38 -0500
>>> Eric Smith <eric at trueblade.com> wrote:
>>>> If we're looking to reduce the number of methods on str, I wouldn't mind
>>>> seeing center() and zfill() also go away, since they're trivially
>>>> replaced by format().
>>>
>>> Well, it's only trivial when you know format()'s wicked mini-language by
>>> heart :/  center() is easy and obvious. zfill() is arguably a bit too
>>> specialized.
>>
>> I've occasionally wondered if string formatting [1] and the struct
>> module [2] would benefit from format building functions that made them
>> easier to use without necessarily learning the cryptic mini-languages
>> off by heart.
>>
>> For example, a "string.make_format_spec" function might have a signature like:
>>
>> def make_format_spec(fill=None, align=None, sign=None, width=None,
>> precision=None, display_type='s', alternate=False, commas=False,
>> numeric_case=None)
>>
>> "align" would accept not only the actual format symbols ('<', '>',
>> '=', '^'), but also the corresponding names ('left', 'right',
>> 'numeric', 'center').
>>
>> "numeric_case" would accept None, 'upper' or 'lower' (affecting the
>> formatting of hex and floating point values). If the stated numeric
>> case differs from that specified by the display type, raise a
>> ValueError. For an unspecified numeric case, the affected display
>> types would default to 'lower'.
>>
>> Similarly, "display_type" would accept long names in addition to the
>> character codes:
>>
>> 's': 'str'
>> 'b': 'binary'
>> 'c': 'chr'
>> 'd': 'int'
>> 'o': 'octal'
>> 'x', 'X': 'hex' (numeric case controls display of digits A-F)
>> 'n': 'locale'
>> 'e', 'E': 'exponent' (numeric case controls display of exponent as
>> well as infinite and NaN values)
>> 'f', 'F': 'float' (numeric case controls display of exponent as well
>> as infinite and NaN values)
>> 'g', 'G': 'general' (numeric case controls display of exponent as well
>> as infinite and NaN values)
>> '%': 'percent' (numeric case controls display of exponent as well as
>> infinite and NaN values)
>>
>> There could also be a corresponding parse_format_spec that produced a
>> named tuple with the appropriate details.
>
> But is this worth it since once you write it you won't be changing it
> again,

Having a make_format_spec() would also help people trying to read the code.

> suggesting that taking the time to look up the formatting rules
> isn't that much harder and wouldn't burden us w/ writing such
> functions and trying to come up with a good API. I suspect what would
> be more helpful is either have a rather detailed docstring for
> str.format or to at least put the URL to the docs which explains the
> mini-language to make it easier to find.
>>
>> Cheers,
>> Nick.
>>
>> [1] http://docs.python.org/dev/library/string#format-specification-mini-language
>> [2] http://docs.python.org/dev/library/struct#format-strings
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jyasskin%40gmail.com
>