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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4