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 _______________________________________________ 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
