[Python-3000] More PEP 3101 changes incoming

[Guido van Rossum]

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 <nicko at nicko.org> 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
> Python-3000 at python.org
> 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/)