I'm busy at the sprints, so I don't have a lot of time to think about this. However, let me just say that recursive format specs are supported, to a depth of 1.
width=10 f'{"test":{width}}' 'test '
So first the string is basically expanded to: f'{"test":10}' Then the string is formatted again to produce the final result. That is why the braces must match: they're being used for recursive format specs. There's no mechanism for having braces that aren't inspected by the f-string machinery. Eric On 5/15/18 2:41 AM, Ken Kundert wrote:
The syntax for formatted string literals is given here: https://docs.python.org/3/reference/lexical_analysis.html#f-strings
If you were to examine this carefully, you would see that a format_spec (the part within the braces but after the colon) can be empty or it can consist of literal characters and replacement fields. For example:
f"result: {value:{width}.{precision}}"
In this case '{width}.{precision}' is the format_spec, it consists of two replacement fields, {width} and {precision}, and one literal character, '.'.
The definition of literal character includes all characters except braces. Presumably excluding braces makes it easier to distinguish the replacement fields. However, replacement fields are also used in the f_string itself, but in that case escaped braces are explicitly added to the list of valid symbols.
I think the fact that one cannot include braces in the format_spec is an unnecessary and undesirable restriction.
As an example of where it would be useful to allow braces in the format_spec, consider this simple example:
>>> class mydict(dict): ... def __format__(self, template): ... return ''.join( ... template.format(v, k=k, v=v) for k, v in self.items() ... )
>>> accounts = mydict(checking=4256.78, savings=12000, brokerage=24685.5) >>> print('Accounts:\n {0:{{k:>9s}}: ${{v:>9,.2f}}\n }'.format(accounts)) Accounts: checking: $ 4,256.78 savings: $12,000.00 brokerage: $24,685.50
In this example, the format_spec is itself treated as a format string, which allows a recursive specification of the string format.
If you try this example in Python3.6 you will find that it works, but it should not because the format_spec contains escaped braces. However, the fact that it works appears be be a happy accident. Things break if the escaped braces are not balanced (thanks to Thomas Jollans for finding this). Furthermore, things break in a different manner when an f-string is used. For example:
>>> print(f'Accounts:\n {accounts:{{k:>9s}}: ${{v:>9,.2f}}\n }') File "<fstring>", line 1 ({k:>9s}) ^ SyntaxError: invalid syntax
or:
>>> print(f'Accounts:\n {accounts:{{k}}: ${{v}}\n }') File "tryit", line 12, in <module> print(f'Accounts:\n {accounts:{{k}}: ${{v}}\n }') NameError: name 'k' is not defined
Oddly, the f-string still raises the NameError even if both k and v are explicitly defined.
At a minimum it would be good to improve the error messages that are produced when escaped braces are included in the format_spec. Most of the error messages that are given, if they are given at all, are misleading. None are as simple as:
SyntaxError: escaped braces are not allowed in a format spec.
But rather than improve the error messages, I think we should consider simply allowing escaped braces in the format_spec. Doing so enables the neat idea of recursive format strings. But even if you don't like that idea, it would be nice to remove this rather rather odd restriction and would make the behavior of f-strings and the format method more consistent.
-Ken _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/