[Python-Dev] PEP 3101 Update

[Guido van Rossum]

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/)