[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