[Python-3000] PEP - string.format

[Giovanni Bajo]

Talin wrote:

> http://viridia.org/python/doc/PEP_AdvancedStringFormatting.txt

Some comments:

- Could this be implemented as a "preview" in Python 2.x? Do we want to?
- I like having an operator for string formatting. I'm -0 on dropping it for
a .format() method.
- string.Template becomes obsolete with this PEP (as my understanding is
that it was added only to provide positional arguments). Of course other
people will have other templating libraries (outside stdlib), but I can't
see why you shouldn't declare string.Template obsoleted by this PEP. It
violates TOOWTDI for no good reason.
- Provide rationale for defaulting to a positional-argument style. It's a
good choice IMO, but you should explain why it's good to say {0} {1} instead
of {d} {i} or similar.
- You say that {} is unspecified. Why don't it make it mean "previous
positional argument + 1"?
- I'm confused as why your datetime example uses {0:%x} instead of {0:x}.
- I'm not sure what __format__ buys you over __unicode__ / __str__. I know
there is the additional "specifiers" argument, but maybe there is a way we
can unify the two things in Py3k.
- I feel strongly that we ought to have a way to implicitly refer to
locals() in string formatting. I like your solution in which the formatting
operation is explicit (so that a string is not magically interpolated ala
Perl, which I find inconvenient), but the locals() dictionary is assumed by
default. IMO, it doesn't need a new method, simply calling .format() with no
arguments is clear and elegant. My second favourite is the backtick which is
free again in Python 3.0.
- The PEP is mixmatching the issue of have a simple way to spell
.format(**locals()) with the issue of allowing arbitrary complex expressions
within the format specifiers. I see that you think that {parser.line} is
useful, but I don't see why "Error in file {0.file}, line
{0.line}".format(parser) is less useful (notice that using {0},{1} with
format(parser.file, parser.line) could be said to violate the "spell it
once" principle). I think the two issues should be separated.
- As for supporting expression like {a.b} in format specifiers, I'm -0. If
we go that way, we end up with Cheetah or whatever. Specifically, why should
we allow {a.b} and not {a[0]}? And {a[0].b}? And {a[k].b}? And {a[k+1].b}?
And {a[{x}].b}? Basically, we either allow an eval() within the specified
context or we do nothing. I think I prefer if we do not allow anything.

-- 
Giovanni Bajo