On 6/11/2011 6:32 AM, Petri Lehtinen wrote:
> Nick Coghlan wrote:
> [snip]
It seems to me that the intent of the pep and the current doc is that
field_names should match what one would write in code except that quotes
are left off of literal string keys. Which is to say, the brackets []
serve as quote marks. So once '[' is found, the scanner must shift to
'in index' mode and accept everything until a matching ']' is found,
ending 'in index' mode.
The arg_name is documented as int or identifier and attribute_name as
identifier, period. Anything more than that is an implementation
accident which people should not count on in either future versions or
alternate implementations.
I can imagine uses for nested replacement fields in the field_name or
conversion spec. Ie, '{ {0}:{1}d'.format(2,5,333,444) == ' 333',
whereas changing the first arg to 3 would produce ' 444'. If braces are
allowed in either of the first two segments (outside of the 'quoted'
within braces context), I think it should only be for the purpose of a
feature addition that makes them significant.
It strikes me that the underlying problem is that the replacement_field
scanner is, apparently, hand-crafted rather than being generated from
the corresponding grammar, as is the overall Python lexer-parser. So it
has no necessary connection with the grammar.
--
Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4