[Python-Dev] PEP 3101 implementation vs. documentation

[Ben Wolfson]

On Sat, Jun 11, 2011 at 4:29 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Ben Wolfson wrote:
>>
>> You can't have an internal replacement
>> field in this part of the replacement field, so '{' can always safely
>> be assumed to be Just a Brace and not the start of a replacement
>> field, regardless of whether it's doubled,
>
> I'm worried that the rules in this area are getting too
> complicated for a human to follow. If braces are allowed
> as plain data between square brackets and/or vice versa,
> it's going to be a confusing mess to read, and there will
> always be some doubt in the programmer's mind as to whether
> they have to be escaped somehow or not.
>
> I'm inclined to think that any such difficult cases should
> simply be disallowed. If the docs say an identifier is required
> someplace, the implementation should adhere strictly to that.

There are two cases with the braces: attribute selection and item
selection. The docs say that attributes should be identifiers, and
that the argument name should be an integer or an identifier, but that
the item selector can essentially be an arbitrary string as long as it
doesn't contain ']', which indicates its end. The docs as they stand
suggest that braces in item selectors should be treated as plain data:

"""
Format strings contain “replacement fields” surrounded by curly braces
{}. Anything that is not contained in braces is considered literal
text, which is copied unchanged to the output. If you need to include
a brace character in the literal text, it can be escaped by doubling:
{{ and }}.
"""

Since it mentions escaping only in the context of how to get a brace
in literal text rather than in a replacement field.

Current behavior is to perform escapes in the format spec part of a
replacement field, and that, I think, makes sense, since there can be
an internal replacement field there. However, it's still pretty simple
to tell whether braces need to be escaped or not: a brace in the
format spec does need to be escaped, a brace before the format spec
doesn't.

> It's not *that* hard to parse an indentifier properly, and
> IMO any use case that requires putting arbitrary characters
> into an item selector is abusing the format mechanism and
> should be redesigned to work some other way.

If by "item selector" you mean (using the names from the grammar in
the docs) the element_index, I don't see why this should be the case;
dictionaries can contain non-identified keys, after all. If you mean
the attribute_name (and arg_name) parts, then requiring an identifier
(or an integer for arg_name) makes a lot more sense.

I assume that Talin had some reason for stating otherwise in the PEP
(one of the few things that does get explicitly said about the
field_name part), but I'm kind of at a loss for why; you would need to
have a custom __getattribute__ to exploit it, and it would be a lot
less confusing just to use __getitem__.

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]