[Python-3000] PEP - string.format

[Talin]

Giovanni Bajo <rasky <at> develer.com> writes:

> Talin wrote:
> 
> > http://viridia.org/python/doc/PEP_AdvancedStringFormatting.txt
> 
> Some comments:

Excellent feedback. I won't address everything at once - instead I'd like to 
collect feedback from various people and address the issues all at once.

However, there's a few things I want to answer right away:
 
> - Could this be implemented as a "preview" in Python 2.x? Do we want to?

That is certainly a possibility. I have no opinion on this, but I'd be 
interest to know what the community wants.

> - 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.

I'll let other people decide on what's obselete or not.

> - I'm confused as why your datetime example uses {0:%x} instead of {0:x}.

The idea was that the specifier could be passed unmodified to the strftime() 
function. "%x" is interpreted by strftime() as meaning "the date in the 
current locale."

> - 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.

I'm not wedded to the idea, and I'd be happy to drop that whole part of if 
that's what folks want. (That's why I labeled that section "Optional".)

The selection of which expressions to support in string templates was based on 
an informal, seat-of-the-pants estimate of the security risk of various 
operations. In other words, the partition between what's allowed and what 
isn't is not based on a logical, mathematical rule, but based on history and 
practice, which is much messier.

-- Talin