[Python-Dev] transitioning from % to {} formatting (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Sep 30 12:43:50 CEST 2009

Steven Bethard wrote:

So I understand how this might help a user to move from %-style formatting to {}-style formatting, but it's still not clear to me how to use this to evolve an API. In particular, if the goal is for the API to move from accepting %-style format strings to {}-style format strings, how should that API use newstyleformatstr or oldstyleformatstr to make this transition?

The problem is that many (most?) of the problematic APIs (such as logging) will have multiple users in a given application, so getting the granularity of any behavioural switches right is going to be difficult.

Providing a formatstr() type that makes .mod() work based on a .format() style string (and a formatmod() type that does the opposite) would allow for extremely fine-grained decision making, since every format string will either be an ordinary str instance or else an instance of the formatting subclass.

(Note that the primary use case for both proposed types is an application developer adapting between two otherwise incompatible third party libraries - the choice of class just changes based on whether the old code being adapted is the code invoking mod on a format string or the code providing a format string that expects to be used with the mod operator).

I don't see any way for delayed formatting of "normal" strings in any existing API to move away from %-formatting except via a long and painful deprecation process (i.e. first warning when bare strings are used for a release or two, then switching entirely to the new formatting method) or by duplicating the API and maintaining the two interfaces in parallel for the foreseeable future.

As Paul noted, the two proposed classes may also be useful to the library developer during such a transition process - they could accept strings in the "wrong" format just by wrapping them appropriately rather than having to maintain the parallel APIs all the way through the software stack.

Probably worth letting these concepts bake for a while longer, but it definitely be nice to do something to help enable this transition in 2.7/3.2.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list