My apologies, as I've read through this thread again and haven't found the reason the approach last mentioned by Eric S. was abandoned: f'{a[name]}' ==> '{[name]}'.format(a) This seemed to solve things neatly, letting .format() handle the messy details it already handles. Also it's easy to lift the identifier names out using their rules. Simple implementation, easy to understand. Then conversation switched to this alternative: f'{a[name]}' ==> '{}'.format(a['name']) Which has the drawback that some of the complexity of the mini-language will need to be reimplemented. Second, there is an inconsistency in quoting of string dictionary keys. That's unfortunate, but the way format currently works. Since f'' will be implemented on top, is not the quoting issue orthogonal to it? If the unquoted str dict key is indeed unacceptable I submit it should be deprecated (or not) separately, but not affect the decision on f''. Again though, I feel like I'm missing an important nugget of information. -Mike On 07/21/2015 10:58 AM, Guido van Rossum wrote:
On Tue, Jul 21, 2015 at 6:50 PM, Oscar Benjamin <oscar.j.benjamin@gmail.com <mailto:oscar.j.benjamin@gmail.com>> wrote:
On Tue, 21 Jul 2015 at 14:14 Nick Coghlan <ncoghlan@gmail.com <mailto:ncoghlan@gmail.com>> wrote:
I wonder though, if we went with the f-strings idea, could we make them support a *subset* of the "str.format" call syntax, rather than a superset? What if they supported name and attribute lookup syntax, but not positional or subscript lookup?
Please don't do either. Python already has a surplus of string formatting mini-languages. Making a new one that is similar but not the same as one of the others is a recipe for confusion as well as an additional learning burden for new users of the language.
I'm not sure if you meant it this way, but if we really believed that, the only way to avoid confusion would be not to introduce f'' strings at all. (Which, BTW is a valid outcome of this discussion -- even if a PEP is written it may end up being rejected.)
Personally I think that the different languages are no big deal, since realistically the far majority of use cases will use simple variables (e.g. foo) or single attributes (e.g. foo.bar).
Until this discussion I had totally forgotten several of the quirks of PEP 3101, including: a[c] meaning a['c'] elsewhere; the ^ format character and the related fill/align feature; nested substitutions; the top-level format() function. Also, I can never remember how to use !r.
I actually find quite unfortunate that the formatting mini-language gives a[c] the meaning of a['c'] elsewhere, since it means that the formatting mini-language to reference variables is neither a subset nor a superset of the standard expression syntax. We have a variety of other places in the syntax where a slightly different syntax is supported (e.g. it's quite subtle how commas are parsed, and decorators allow a strict subset of expressions) but the formatting mini-language is AFAIR the only one that gives a form that is allowed elsewhere a different meaning.
-- --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/