[Python-Dev] PEP 3101 Update (original) (raw)

Guido van Rossum guido at python.org
Fri May 19 08:37:49 CEST 2006

On 5/6/06, Talin <talin at acm.org> wrote:

I've updated PEP 3101 based on the feedback collected so far. [http://www.python.org/dev/peps/pep-3101/]

I think this is a step in the right direction.

I wonder if we shouldn't borrow more from .NET. I read this URL that you referenced:

http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcompositeformatting.asp

They have special syntax to support field width, e.g. {0,10} formats item 0 in a field of (at least) 10 positions wide, right-justified; {0,-10} does the same left-aligned. This is done independently from the type-specific formatting. (I'm not proposing that we use .NET's format specifiers after the colon, but I'm also no big fan for keeping the C specific stuff we have now; we should put some work in designing something with the same power as the current %-based system for floats and ints, that would cover it.)

.NET's solution for quoting { and } as {{ and }} respectively also sidesteps the issue of how to quote \ itself -- since '\{' is a 2-char string containing one \ and one {, you'd have to write either '\\{0}' or r'\{0}' to produce a single literal \ followed by formatted item 0. Any time there's the need to quadruple a backslash I think we've lost the battle. (Or you might search the web for Tcl quoting hell. :-)

I'm fine with not having a solution for doing variable substitution within the format parameters. That could be done instead by building up the format string with an extra formatting step: instead of "{x:{y}}".format(x=whatever, y=3) you could write "{{x,{y}}}".format(y=3).format(x=whatever). (Note that this is subtle: the final }}} are parsed as } followed by }}. Once the parser has seen a single {, the first } it sees is the matching closing } and adding another } after it won't affect it. The specifier cannot contain { or } at all.

I like having a way to reuse the format parsing code while substituting something else for the formatting itself.

The PEP appears silent on what happens if there are too few or too many positional arguments, or if there are missing or unused keywords. Missing ones should be errors; I'm not sure about redundant (unused) ones. On the one hand complaining about those gives us more certainty that the format string is correct. On the other hand there are some use cases for passing lots of keyword parameters (e.g. simple web templating could pass a fixed set of variables using **dict). Even in i18n (translation) apps I could see the usefulness of allowing unused parameters

On the issue of {a.b.c}: like several correspondents, I don't like the ambiguity of attribute vs. key refs much, even though it appears useful enough in practice in web frameworks I've used. It seems to violate the Zen of Python: "In the face of ambiguity, refuse the temptation to guess."

Unfortunately I'm pretty lukewarm about the proposal to support {a[b].c} since b is not a variable reference but a literal string 'b'. It is also relatively cumbersome to parse. I wish I could propose {a+b.c} for this case but that's so arbitrary...

Even more unfortunately, I expect that dict key access is a pretty important use case so we'll have to address it somehow. I don't think there's an important use case for the ambiguity -- in any particular situation I expect that the programmer will know whether they are expecting a dict or an object with attributes.

Hm, perhaps {a at b.c} might work? It's not an existing binary operator. Or perhaps # or !.

It's too late to think straight so this will have to be continued...

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list