On Sat, Jun 11, 2011 at 2:16 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On Sat, Jun 11, 2011 at 7:15 AM, Ben Wolfson <wolf...@gmail.com> wrote:
> To summarise (after both the above post and the discussion on the tracker)
Thanks for the summary!
>
> That would leave us with the following set of rules for name fields:
>
> 1. Numeric fields start with a digit and are terminated by any
> non-numeric character.
>
> 2. An identifier name field is terminated by any one of:
> '}' (terminates the replacement field, unless preceded by a
> matching '{' character, in which case it is ignored and included in
> the string)
> '!' (terminates identifier field, starts conversion specifier)
> ':' (terminates identifier field, starts format specifier)
> '.' (terminates identifier field, starts new identifier field for
> subattribute)
> '[' (terminates identifier field, starts index field)
>
> 3. An index field is terminated by ']' (subsequent character will
> determine next field)
A minor clarification since I mentioned a patch: the patch as it
exists implements *these*---Nick's---semantics. That is, it will allow
these:
"{0.{a}}".format(x)
"{0.{[{].}}".format(x)
But not this, because it keeps current brace-matching in this context:
"{0.{a}".format(x)
And it treats this:
"{0.a}}".format(x)
as the markup "{0.a}" followed by the character data "}".
The patch would have to be changed to turn off brace balancing in name
fields as well.
In either case there would be potential breakage, since this:
"{0[{}.}}".format(...)
currently works, but would not work anymore, under either set of
rules. (The likelihood that this potential breakage would anywhere be
actual breakage is pretty slim, though.)
> Note that brace-escaping currently doesn't work inside name fields, so
> that should also be fixed:
>
>>>> "{0[{{]}".format({'{':1})
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: unmatched '{' in format
>>>> "{a{{}".format(**{'a{':1})
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: unmatched '{' in format
This is a slightly different issue, though, isn't it? As far as I can
tell, if the brace-matching rules are kept in place, there would never
be any *need* for escaping. 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, and '}' will either be in
an index field (where it can't have the significance of ending the
replacement field) or it will be (a) the end of the replacement field
or (b) not the end of the replacement field because matched by an
earlier '{'. So there would never be any role for escaping to play.
There would be a role for escaping if the rules for name fields are
that '}' terminates them, no matching done; then, you could double
them to get a '}' in the name field. But, to be honest, that strikes
me as introducing a lot of heavy machinery for very little gain;
opening and closing braces would have to be escaped to accomodate this
one thing. And it's not as if you can escape ']' in index
fields---which would be a parallel case. It seems significantly
simpler to me to leave the escaping behavior as it is in this part of
the replacement field.
--
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]
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
