Martin v. Löwis wrote:
> Steven Bethard wrote:
>> There's a lot of code already out there (in the standard library and
>> other places) that uses %-style formatting, when in Python 3.0 we
>> should be encouraging {}-style formatting.
>
> I don't agree that we should do that. I see nothing wrong with using
> % substitution.
It's a maintenance burden. There are several outstanding bugs with it,
admittedly not of any great significance. I've been putting time into
fixing at least one of them. When Mark and I did short-float-repr, at
least half of my time was consumed with %-formatting, mostly because of
how it does memory management.
On the plus side, %-formatting is (and always will be) faster than
str.format(). Its very limitations make it possible for it to be fast.
I'd note that PEP 3101 calls str.format() a replacement for
%-formatting, not an alternate mechanism to achieve the same end.
>> * Add a new class, NewFormatter, which uses the {}-style formatting.
>> This is ugly because it makes the formatting we're trying to encourage
>> look like the alternative implementation instead of the standard one.
>
> It's also ugly because the class has the word "new" in its name, which
> no class should ever have. In a few years, it would still be around,
> but not new anymore.
>
>> * Have Formatter convert all %-style formatting strings to {}-style
>> formatting strings (automatically). This still involves some guessing,
>> and involves some serious hacking to translate from one to the other
>> (maybe it wouldn't even always be possible?). But at least we'd only
>> be using {}-style formatting under the hood.
>
> I don't see the point of having a converter. The tricky part, as you
> say, is the guessing. Whether the implementation then converts the
> string or has two alternative formatting algorithms is an implementation
> detail. I would favor continued use of the actual % substitution
> code.
Having a converter and guessing are 2 distinct issues. I believe a
convert from %-formatting specification strings to str.format() strings
is possible. I point this out not because I think a converter solves
this problem, but because in the past there's been a debate on whether a
converter is even possible.
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