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

Paul Moore p.f.moore at gmail.com
Wed Sep 30 11:18:38 CEST 2009

2009/9/30 Steven Bethard <steven.bethard at gmail.com>:
> On Tue, Sep 29, 2009 at 10:04 PM, James Y Knight <foom at fuhm.net> wrote:
>> 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.
> 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?

IIUC, the API doesn't change. It's just that the internal code goes as follows:

1. (Current) Use %. str and oldformat objects work as now, newformat
objects work (using .format).
2. Convert the code to use .format - oldformat and newformat objects
work as before, str objects must be in new format.

The problem is, there's a point at which bare str arguments change
behaviour. So unless people wrap their arguments when calling the API,
there's still a point when things break (albeit with a simple
workaround available).

So maybe we need transition steps - wrap bare str objects in oldformat
classes, and warn, then wrap str objects in newformat objects and
warn, then stop wrapping.

That sounds to me like "normal" usage (bare strings) will be
annoyingly painful for a substantial transition period.

I'm assuming that the oldformat and newformat classes are intended to
be transitional things, and there's no intention that users should be
using the wrapper objects always. (And of course better names than
"oldformat" and "newformat" are needed - as Martin pointed out, having
"old" and "new" in the names is inappropriate). Otherwise, I'm a
strong -1 on the whole idea.


More information about the Python-Dev mailing list