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

Christian Tanzer tanzer at swing.co.at
Thu Oct 8 17:08:29 CEST 2009

Eric Smith wrote at Thu, 08 Oct 2009 10:55:21 -0400:

>>> BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see if it was >>> worth raising an enhancement request on the bug tracker using "O" to generate >>> compatible rendering for octals. >> I didn't get your message, could you resend?. >> >> I was thinking the same thing, but it seems like a transition step. I'd >> rather not keep such backward compatibility hacks (if you will) around >> for the long haul. How about a flag (maybe '*') at the start of the >> format specification which says "operate in backward compatibility >> mode"? We could document it as being only useful for the % to {} >> translator, and promise to remove it at some point in the future. Either >> actually deprecate it or just promise to deprecate it in the future. > > That doesn't seem very useful to me. IIUC, the point of the translator > is to allow porting of the millions of existing %-formating operations > to the new-style .format. > > If the result of that is deprecated or removed a few years from now, > all maintainers of long existing code have exactly the same problem.

I was thinking of it as a transition step until all application code switched to {} formatting. In which case the application has to deal with it.

You lost me here.

All that talk of deprecating %-formatting makes me really nervous. %-formatting is pervasive in all existing Python code.

Without an automatic translator that is 100% accurate, porting all that code to {}-formatting is not possible. Heck, it's not even possible to grep for all instances of %-formatting.

How do you suppose that maintainers could ever do the transition from %- to {}-formatting manually?

> IMHO, either the translation is done once and gives identical output or > it isn't worth doing at all.

I disagree. I doubt even 0.001% of all format strings involve octal formatting. Is it really worth not providing a transition path if it can't cover this case?

If %-formatting is first deprecated then removed from Python and there is no automatic transition path that effectively means that existing code using %-formatting is forced to stay at whatever Python version was the last one supporting %-formatting.

I surely hope nobody is seriously considering such a scenario. Perl 6 seems harmless in comparison.

-- Christian Tanzer http://www.c-tanzer.at/

More information about the Python-Dev mailing list