[Python-3000] More PEP 3101 changes incoming

Ron Adam rrr at ronadam.com
Fri Aug 10 20:09:13 CEST 2007



Greg Ewing wrote:
> Ron Adam wrote:
>>     - alter the value and return (new_value, format_spec)
>>     - alter the format_spec and return (value, new_format_spec)
>>     - do logging of some values, and return the (value, format_spec) 
>> unchanged.
> 
> I would ditch all of these. They're not necessary, as
> the same effect can be achieved by explicitly calling
> another __format__ method, or one's own __format__
> method with different args, and returning the result.

I'm not sure what you mean by "ditch all of these".  Do you mean not 
document them, or not have the format function do anything further on the 
(value, format_spec) after it is returned from the __format__ method?


>>     - do something entirely different and return ('', None)
> 
> I don't understand. What is meant to happen in that case?

The output in this case is a null string. Setting the format spec to None 
tell the format() function not to do anything more to it.

What ever else happens in the __format__ method is up to the programmer.


>> Does this look ok, or would you do it a different way?
> 
> You haven't explained how this addresses the 'r' issue
> without requiring every __format__ method to recognise
> and deal with it.

The format function recognizes and deals with 'r' just as you suggest, but 
it also recognizes and deals with all the other standard formatter types in 
the same way.

The format function would first call the objects __format__ method and give 
it a chance to have control, and depending on what is returned, try to 
handle it or not.

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.

Ron






More information about the Python-3000 mailing list