[Python-ideas] Briefer string format

[Mike Miller]

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 at gmail.com
> <mailto:oscar.j.benjamin at gmail.com>> wrote:
>
>     On Tue, 21 Jul 2015 at 14:14 Nick Coghlan <ncoghlan at gmail.com
>     <mailto:ncoghlan at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>