[Python-3000] More PEP 3101 changes incoming

[Ron Adam]

Greg Ewing wrote:
> Ron Adam wrote:
>> Greg Ewing wrote:
>  >
>>> How does this work with formats where the number of
>>> digits before the decimal can vary, but before+after
>>> is constant?
>> I think this is what you're looking for.
>>
>>    f>15,.3   #15 field width, 3 decimal places, right aligned.
> 
> No, I'm talking about formats such as "g" where the
> number of significant digits is fixed, but the position
> of the decimal point can change depending on the magnitude
> of the number. That wouldn't fit into your before.after
> format.

It would probably just a number with no decimal point in it.  Something 
like 'g10' seems simple enough.  You will always have the 'g' in this case.


>>> Also, my feeling about the whole of this is that
>>> it's too complicated.
>> it's because we are doing a lot in a very little space.
> 
> Yes, and I think you're trying to do a bit too much.
> The format strings are starting to look like line
> noise.

Do you have a specific example or is it just an overall feeling?


One of the motivations for finding something else is because the % 
formatting terms are confusing to some. A few here have said they need to 
look them up repeatedly and have difficulty remembering the exact forms and 
order.

And part of it is the suggestion of splitting it up into parts that are 
interpreted by the objects __format__ method, and a part that are 
interpreted by the format function.  For example the the field alignment 
part can be handled by the format function, and the value format part can 
be handled by the __format__ method.  It helps to have the alignment part 
be well defined and completely separate from the content formatter part in 
this case.  And it saves everyone from having to parse and implement 
alignments in there format methods.  I think that is really the biggest 
reason to do this.

I'm not sure you can split up field aligning and numeric formatting that 
way when using the % style formatting.  They are combined too tightly.  So 
each type would need to do both in it's __format__ method.  And chances are 
there will be many types that do one or the other but not both just because 
it's too much work, or just due to plain laziness.

So before we discard this, I'd like to see a full working version with 
complete __format__ methods for int, float, and str types and any 
supporting functions they may use.

And my apologies if its starting to seem like line noise.  I'm not that 
good at explaining things in simple ways.  I tend to add too much detail 
when I don't need to, or not enough when I do.  A complaint I get often 
enough.  But I think this one is fixable by anyone who is a bit better at 
writing and explaining things in simple ways than I am. :-)

Cheers,
   Ron