[Python-Dev] Migration strategy for new-style string formatting [Was: Binary Operator for New-Style String Formatting]

James Y Knight foom at fuhm.net
Mon Jun 22 14:30:49 CEST 2009

On Jun 21, 2009, at 5:40 PM, Eric Smith wrote:
> I've basically come to accept that %-formatting can never go away,  
> unfortunately. There are too many places where %-formatting is used,  
> for example in logging Formatters. %-formatting either has to exist  
> or it has to be emulated.

It'd possibly be helpful if there were builtin objects which forced  
the format style to be either newstyle or oldstyle, independent of  
whether % or format was called on it.

x = newstyle_formatstr("{} {} {}")
x % (1,2,3) == x.format(1,2,3) == "1 2 3"

and perhaps, for symmetry:
y = oldstyle_formatstr("%s %s %s")
y.format(1,2,3) == x % (1,2,3) == "1 2 3"

This allows the format string "style" decision is to be made external  
to the API actually calling the formatting function. Thus, it need not  
matter as much whether the logging API uses % or .format() internally  
-- that only affects the *default* behavior when a bare string is  
passed in.

This could allow for a controlled staged towards the new format string  
format, with a long deprecation period for users to migrate:

1) introduce the above feature, and recommend in docs that people only  
ever use new-style format strings, wrapping the string in  
newstyle_formatstr() when necessary for passing to an API which uses %  
2) A long time later...deprecate str.__mod__; don't deprecate  
3) A while after that (maybe), remove str.__mod__ and replace all  
calls in Python to % (used as a formatting operator) with .format() so  
that the default is to use newstyle format strings for all APIs from  
then on.


More information about the Python-Dev mailing list