[Python-3000] More PEP 3101 changes incoming

Ron Adam rrr at ronadam.com
Mon Aug 6 06:47:36 CEST 2007



Greg Ewing wrote:
> Ron Adam wrote:
>>      return value.__format__(format_spec, abstract)
> 
> Why would the __format__ method need to be passed an
> 'abstract' flag? It can tell from the format_spec if
> it needs to know.

I may have been thinking too far ahead on this one.  I first wrote that 
without the abstract flag, but then changed it because it seemed there was 
an ambiguous situations that I thought this would clear up.

I think i was thinking of a way to offer a generic way to tell a __format__ 
method weather or not to raise an exception or fall back to str or repr.


lets say a string __format__ method looks like the following...

    def __format__(self, specifier, abstract=False):
       if not specifier or specifier[0] == 's' or abstract:
           return self
       raise(ValueError, invalid type for format specifier.)

It would be more complex than this in most cases, but it doesn't need to 
know about any other specifier types to work.  Of course string types don't 
need to fall back, but that doens't mean it is away s desirable for them to 
succeed.


For example if we have...

     '{0:k10}'.format('python')

Should it even try to succeed, or should it complain immediately?

If the string __format__ method got 'k10' as a format specifier, it has no 
idea what the 'k10' is suppose to mean, it needs to make a choice to either 
fall back to str(), or raise an exception that could be caught and handled.

So,

Is it useful to sometimes be strict an at other times forgive and fall back?

And if so, how can we handle that best?

(The exact mechanism can be figured out later, its the desired behaviors 
that needs to be determined for now.)

Cheers,
    Ron












More information about the Python-3000 mailing list