On Oct 1, 2009, at 6:19 PM, Steven Bethard wrote:
> I see how this could allow a user to supply a {}-format string to an
> API that accepts only %-format strings. But I still don't see the
> transition strategy for the API itself. That is, how does the %-format
> API use this to eventually switch to {}-format strings? Could someone
> please lay it out for me, step by step, showing what happens in each
> version?
Here's what I said in my first message, suggesting this change.
Copy&pasted below:
I wrote:
> 1) introduce the above feature, and recommend in docs that people
> only ever use new-style format strings, wrapping the string in
> newstyle_formatstr() when necessary for passing to an API which uses
> % internally.
> 2) A long time later...deprecate str.__mod__; don't deprecate
> newstyle_formatstr.__mod__.
> 3) A while after that (maybe), remove str.__mod__ and replace all
> calls in Python to % (used as a formatting operator) with .format()
> so that the default is to use newstyle format strings for all APIs
> from then on.
So do (1) in 3.2. Then do (2) in 3.4, and (3) in 3.6. I skipped two
versions each time because of how widely this API is used, and the
likely pain that doing the transition quickly would cause. But I guess
you *could* do it in one version each step.
James
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