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

[Eric Smith]

Martin v. Löwis wrote:
> Steven Bethard wrote:
>> There's a lot of code already out there (in the standard library and
>> other places) that uses %-style formatting, when in Python 3.0 we
>> should be encouraging {}-style formatting. 
> 
> I don't agree that we should do that. I see nothing wrong with using
> % substitution.

It's a maintenance burden. There are several outstanding bugs with it, 
admittedly not of any great significance. I've been putting time into 
fixing at least one of them. When Mark and I did short-float-repr, at 
least half of my time was consumed with %-formatting, mostly because of 
how it does memory management.

On the plus side, %-formatting is (and always will be) faster than 
str.format(). Its very limitations make it possible for it to be fast.

I'd note that PEP 3101 calls str.format() a replacement for 
%-formatting, not an alternate mechanism to achieve the same end.

>> * Add a new class, NewFormatter, which uses the {}-style formatting.
>> This is ugly because it makes the formatting we're trying to encourage
>> look like the alternative implementation instead of the standard one.
> 
> It's also ugly because the class has the word "new" in its name, which
> no class should ever have. In a few years, it would still be around,
> but not new anymore.
> 
>> * Have Formatter convert all %-style formatting strings to {}-style
>> formatting strings (automatically). This still involves some guessing,
>> and involves some serious hacking to translate from one to the other
>> (maybe it wouldn't even always be possible?). But at least we'd only
>> be using {}-style formatting under the hood.
> 
> I don't see the point of having a converter. The tricky part, as you
> say, is the guessing. Whether the implementation then converts the
> string or has two alternative formatting algorithms is an implementation
> detail. I would favor continued use of the actual % substitution
> code.

Having a converter and guessing are 2 distinct issues. I believe a 
convert from %-formatting specification strings to str.format() strings 
is possible. I point this out not because I think a converter solves 
this problem, but because in the past there's been a debate on whether a 
converter is even possible.

Eric.