[Python-3000] More PEP 3101 changes incoming

[Ron Adam]

Jim Jewett wrote:
> On 8/13/07, Ron Adam <rrr at ronadam.com> wrote:
>> I reconsidered the split term forms a bit more and I think I've come up
>> with a better way to think about them. Sometimes a slight conceptual
>> shift can make a difference.
> 
>> The basic form is:
> 
>>        {name[:][type][alignment_term][,content_modifying_term]}
> 
> That sounds good, but make sure it works in practice; I think you were
> already tempted to violate it yourself in your details section.  You
> used the (alignment term) width as the number of digits before the
> decimal, instead of as the field width.

I have a test version to test these ideas with.  It's uses a centralized 
parser rather the the distributed method that has been decided on, but it's 
good for testing the syntax.  In some ways it's easier for that.

You can leave out either term.  So that may have been what you are seeing.


There are more details that can be worked out.

You can also switch the order of the terms.  But I'm leaning towards having 
it always process the terms left to right.  For example you might have...

    {0:!r,s+30,<30}

So in this case, it would first do a repr(), then trim long strings to 30 
characters, then left align them in a field 30 characters wide.

But I haven't tested the idea of left to right sequential formatting yet as 
I need to move a lot of stuff around in my test implementation to get that 
to work.

Even with that, the most common cases are just single terms, so it adds 
capability for those who want it, or need it, without penalizing newbies.

     {0:f8.2}
   or
     {0:^30}

Simple expression like these will be what is used 9 out 10 times.


>> TYPE:
>>         The specifier type.  One of 'deifsrx'.
>>                 (and any others I left off)
> 
> There should be one that says "just trust the object, and if it
> doesn't have a __format__, then gripe".  (We wouldn't need to support
> arbitrary content_modifying_terms unless it were possible to use more
> than the builtin types.)

That's the default behavior sense the object gets it first.


>> ALIGNMENT TERM:   [direction]width[/fill]
>>
>>      direction:    is one of   '<^>'
>>      width:        a positive integer
>>      /fill:         a character
> 
> 
> So this assumes fixed-width, with fill?

Minimal width with fill for shorter than width items.  It expands if the 
length of the item is longer than width.


> Can I leave the width off to say "whatever it takes"?

Yes

> Can I say "width=whatever it takes, up to 72 chars ... but don't pad
> it if you don't need to"?

That's the default behavior.

> (And once you support variable-width, then minimum is needed again.)
> 
> I'm not sure that variable lengths and alignment even *should* be
> supported in the same expression, but it forcing everything to
> fixed-width would be enough of a change that it needs an explicit
> callout.

Alignment is needed for when the length of the value is shorter than the 
length of the field.  So if a field has a minimal width, and a value is 
shorter than that, it will be used.


>>      NUMBERS:   [sign][0][digits][.decimals][%]
> 
> I read Greg's question:
> 
>     How does this work with formats where the number of
>     digits before the decimal can vary, but before+after
>     is constant?
> 
> differently, as about significant figures.  It may be that 403 and
> 14.1 are both valid values, but 403.0 would imply too much precision.
> (Would it *always* be OK to write these as 4.03e+2 and 1.41e+1?)

I've been avoiding scientific notation so far.  :-)  So any suggestions on 
this part will be good.  I think the format would be 'e1.2' or even just 
'e.2'.  It should follow the same pattern if possible.

> Maybe the answer is that sig figs are a special case, and need a
> template with callbacks instead of a format string ... but that
> doesn't feel right.
> 
>>      /fill:         a character
> 
> I think you need to specify it a bit more than that.  Can you use a
> comma? 

Yes, any character after a '/' works.


  (It looks like the start of the content modifier.)  How about
> a quote-mark, or a carriage return?

Quotes (if they match the the string delimiters) will need to be escaped as 
well as new lines, but I don't see any reason why they couldn't be used. 
I'm not sure why you would want to use those, but I lean towards letting 
the programmer figure out that part. ;-)


Cheers,
    Ron