[Python-3000] More PEP 3101 changes incoming

[Ron Adam]

Talin wrote:
> I'm going to address several issues of the discussion, in hopes of 
> short-cutting through some of the debate. I may not be responding to the 
> correct person in all cases.
> 
> Ron Adam wrote:
>> If you want the 'r' specifier to always have precedence over even 
>> custom __format__ methods, then you can do that too, but I don't see 
>> the need.
> 
> In my conversation with Guido, he felt pretty strongly that he wanted 
> 'repr' to be able to override the type-specific __format__ function.
 >
> I'm assuming, therefore, that this is a non-negotiable design 
> constraint. Unfortunately, it's one that completely destroys the nice 
> neat orthogonal design that you've proposed.

It doesn't completely destroy it, but it does create one exception that 
needs to be remembered.  As I said, it doesn't have to be a special syntax. 
  {0:r} is just fine.


> I often find that the best way to reason about irreconcilable design 
> constraints is to reduce them to a set of contradictory logical 
> propositions:
> 
>   a) A __format__ method must be redefine the meaning of a format 
> specifier.
>   b) The 'repr' option must be able to take precedence the __format__ 
> method.
> 
> The only possible resolution to this di-lemma is that the 'repr' option 
> must not be part of the format specifier, but rather must be part of 
> something else.

You are either going to have one or the other, but never both, so there 
isn't any conflict.

    'ojbect: {0:r}'.format(obj)

or

    'object: {0:s}'.format(repr(obj))

These don't collide in any way.  The only question is weather the 'r' 
specifier also allows for other options like width and alignment.


> Assuming that we continue with the assumption that we want to delegate 
> as much as possible to the __format__ methods of individual types, this 
> means that we are pretty much forced to divide the format string into 
> two pieces, which are:
> 
>    1) The part that __format__ is allowed to reinterpret.
>    2) The part that __format__ is required to implement without 
> reinterpreting.

What should not be allowed?  And why?


> Now, as far as delegating formatting between types: We don't need a 
> hyper-extensible system for delegating to different formatters.
> 
> For all Python types except the numeric types, the operation of 
> __format__ is pretty simple: the format specifier is passed to 
> __format__ and that's it. If the __format__ method can't handle the 
> specifier, that's an error, end of story.
> 
> Numeric types are special because of the fact that they are silently 
> inter-convertable to each other. For example, you can add a float and an 
> int, and Python will just do the right thing without complaining. It 
> means that a Python programmer may not always know the exact numeric 
> type they are dealing with - and this is a feature IMHO.
> 
> Therefore, it's my strong belief that you should be able to format any 
> numeric type without knowing exactly what type it is. Which means that 
> all numeric types need to be able to handle, in some way, all valid 
> number format strings. IMHO.
 >
> Fortunately, the set of number types is small and fixed, and is not 
> likely to increase any time soon. And this requirement does *not* apply 
> to any data type other than numbers.

If this is the direction you and Guido want, I'll try to help make it work. 
  It seems it's also what greg is thinking of.

I think to get the python emplementation moving, we need to impliment the 
whole event chain, not just a function.

So starting with a fstr() type and then possibly fint() and ffloat() etc... 
  where each subclass their respective types and add format and __format__ 
methods respectively.  (for now and for testing)

Then working out the rest will be more productive I think.


> ----
> 
> As to the issue of how flexible the system should be:

Umm... I think you got side tracked here.  The below paragraphs are about 
readability and syntax,  not how flexible of the underlying system.

The question of flexibility is more to do with what things can be allowed 
to be overridden, and what things should not.  For example just how much 
control does a __format__ method have?  I thought the idea was the entire 
format specifier is sent to the __format__ method and then it can do what 
it wants with it.  Possibly replacing the specifier altogether and 
initiating another types __format__ method with the substituted format 
specifier.  Which sounds just fine to me and is what I want too.

So far we established the repr formatter can not be over ridden, but not 
addressed anything else or how to do that specifically.  (Weve addressed it 
in generally terms yes, but we haven't gotten into the details.)


> My belief is that one of the primary design criteria for the format 
> specifier mini-language is that it doesn't detract from the readability 
> of the format string.
> 
> So for example, if I have a string "Total: {0:d} Tax: {1:d}", it's 
> fairly easy for me to mentally filter out the "{0:d}" part and replace 
> it with a number, and this in turn lets me imagine how the string might 
> look when printed.
> 
> (The older syntax, 'Total: %d', was even better in this regard, but when 
> you start to use named/numbered fields it actually is worse. And 
> implicit ordering is brittle.)
> 
> My design goal here is relatively simple: For the most common use cases, 
> the format field shouldn't me much longer (if it all) than the value to 
> be printed would be. For uncommon cases, where the programmer is 
> invoking additional options, the format field can be longer, but it 
> should still be kept concise.
> 
> ----
> 
> One final thing I wanted to mention, which Guido reminded me, is that 
> we're getting short on time. This PEP has not yet been officially 
> accepted, and the reason is because of the lack of an implementation. I 
> don't want to miss the boat. (The boat in this case being Alpha 1.)

I'll forward what I've been playing with so you can take a look.  It's not 
the preferred way, but it may have some things in it you can use.  And it's 
rather incomplete still.

Cheers,
    Ron