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

Brett Cannon brett at python.org
Sat Dec 11 20:21:41 CET 2010


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.makeformatspec" function might have a signature like: def makeformatspec(fill=None, align=None, sign=None, width=None, precision=None, displaytype='s', alternate=False, commas=False, numericcase=None) "align" would accept not only the actual format symbols ('<', '>', '=', '^'), but also the corresponding names ('left', 'right', 'numeric', 'center'). "numericcase" 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, "displaytype" 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 parseformatspec 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, 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.

-Brett

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



More information about the Python-Dev mailing list