[Python-Dev] transitioning from % to {} formatting

[Nick Coghlan]

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 newstyle_formatstr or
> oldstyle_formatstr 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
---------------------------------------------------------------