[Python-3000] More PEP 3101 changes incoming

Ron Adam rrr at ronadam.com
Mon Aug 6 10:24:27 CEST 2007



Greg Ewing wrote:
> Ron Adam wrote:
>> It's *not* a default.  The default is to have no max_width.
> 
> You're suggesting it would be a default if you
> *did* specify a max width but no replacement
> char. That's what I'm saying would be a bad
> default.

Absolutely, *for_field_widths* which is string of characters, after the 
formatting step is done.

We could add a numeric max_width that is specific to numbers that default 
to the '*' character if width overflow is done.  As long as the field 
max_width isn't specified or is shorter than the field max_width, it would 
do what you want.

We could have a pre_process step that adjusts the format width to be within 
the field min-max range or raises an exception if you really want that.


     {0:d,10+20}      # Field width are just string operations done after
                      # formatting is done.

     {0:d10+20}       # Numeric widths,  differ from field widths.
                      # They are specific to the type so can handle special
                      # cases.


Now here's the problem with all of this.  As we add the widths back into 
the format specifications, we are basically saying the idea of a separate 
field width specifier is wrong.

So maybe it's not really a separate independent thing after all, and it 
just a convenient grouping for readability purposes only.

So in that case there is no field alignment function, and it's up to the 
__Format__ method to do both.  :-/

Cheers,
    Ron













More information about the Python-3000 mailing list