Christian Tanzer wrote:
Eric Smith wrote at Thu, 08 Oct 2009 10:24:33 -0400:
Vinay Sajip wrote:
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.
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? Eric.