>>> The positional parameter would also mean dicttemplate, and >>> would be deprecated (eventually requiring a keyword-only >>> parameter). >> >> Although I hate the name 'dicttemplate', this seems like the best solution >> to me. Maybe it's good that 'dicttemplate' is so ugly though so that people >> will naturally prefer 'format' :). But I like this because there's not >> really any magic, it's explicit, and the decision is made by the coder at >> the call site. The implementation does not need to guess at all. > > Could you comment on what you think we should do when the parameter is > not positional? As I mentioned upthread, in the case of > logging.Formatter, it's already documented as taking the keyword > parameter "fmt", so we'd have to use the name "fmt" for % formatting. Unless there is a firm decision to switch to kill %-formatting across the board, I don't think anything should be done at all. Creating Py3.x was all about removing cruft and clutter. I don't think it would be improved by adding two ways to do it for everything in the standard library. That is a lot of additional code, API expansion, and new testing, fatter docs, and extra maintenance, but giving us no new functionality. Anytime we start hearing about newstyle/oldstyle combinations, I think a flag should go up. Anytime there is a proposal to make sweeping additions that do not add new capabilities, a flag should go up. I understand the desire to have all formatting support both ways, but I don't think it is worth the costs. People *never* need both ways though they may have differing preferences about which *one* to use. my-two-cents, Raymond
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