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/