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

Steven Bethard steven.bethard at gmail.com
Wed Sep 30 09:35:18 CEST 2009

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.
> E.g.
> 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 switch 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 % internally.
> 2) A long time later...deprecate str.__mod__; don't deprecate
> newstyle_formatstr.__mod__.
> 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.

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?

Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

More information about the Python-Dev mailing list