Personally I think support for the various accounting-style output is not worth it. I betcha any accounting system worth the name would not use this and instead have its own custom code for formatting anyway.
My personal suggestion is to stay close to the .NET formatting language: name_specifier [',' width_specifier] [':' conversion_specifier] where width_specifier is a positive or negative number giving the minimum width (negative for left-alignment) and conversion_specifier is passed uninterpreted to the object's __format__ method. In order to support the use cases for %s and %r, I propose to allow appending a single letter 's', 'r' or 'f' to the width_specifier (*not* the conversion_specifier): 'r' always calls repr() on the object; 's' always calls str() on the object; 'f' calls the object's __format__() method passing it the conversion_specifier, or if it has no __format__() method, calls repr() on it. This is also the default. If no __format__() method was called (either because 'r' or 's' was used, or because there was no __format__() method on the object), the conversion_specifier (if given) is a *maximum* length; this handles the pretty common use cases of %.20s and %.20r (limiting the size of a printed value). The numeric types are the main types that must provide __format__(). (I also propose that for datetime types the format string ought to be interpreted as a strftime format string.) I think that float.__format__() should *not* support the integer formatting codes (d, x, o etc.) -- I find the current '%d' % 3.14 == '3' an abomination which is most likely an incidental effect of calling int() on the argument (should really be __index__()). But int.__format__() should support the float formatting codes; I think '%6.3f' % 12 should return ' 12.000'. This is in line with 1/2 returning 0.5; int values should produce results identical to the corresponding float values when used in the same context. I think this should be solved inside int.__format__() though; the generic formatting code should not have to know about this. --Guido On 8/2/07, Nicko van Someren <[EMAIL PROTECTED]> wrote: > On 2 Aug 2007, at 03:01, Talin wrote: > > In general, you can think of the difference between format > > specifier and > > alignment specifier as: > > > > Format Specifier: Controls how the value is converted to a > > string. > > Alignment Specifier: Controls how the string is placed on the > > line. > > > > Another change in the behavior is that the __format__ special > > method can > > only be used to override the format specifier - it can't be used to > > override the alignment specifier. The reason is simple: __format__ is > > used to control how your object is string-ified. It shouldn't get > > involved in things like left/right alignment or field width, which are > > really properties of the field, not the object being printed. > > Say I format numbers in an accounting system and, in the absence of > being able to colour my losses in red, I choose the parentheses sign > representation style (). In this case I'd like to be able to have my > numbers align thus: > 1000 > 200 > (3000) > 40 > (50000) > I.e. with the bulk of the padding applied before the number but > conditional padding after the number if there is no closing bracket. > > If the placement is done entirely outside the __format__ method then > you to make sure that it is documented that, when using the () style > of sign indicator, positive numbers need to have a space placed > either side, e.g. -100 goes to "(100)" but +100 does to " 100 ". If > you do this then it should all come out in the wash, but I think it > deserves a note somewhere. > > Cheers, > Nicko > > _______________________________________________ > Python-3000 mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
