[Python-ideas] Briefer string format

[Guido van Rossum]

OK, fine, I'll say right now that I agree with Eric's arguments for full
expressions.

(Though honestly the whole look of f-strings hasn't quite grown on me. I
wish I could turn back the clock and make expression substitution a feature
of all string literals, perhaps using \{...}, which IIRC I've seen in some
other language.)

On Tue, Aug 4, 2015 at 10:20 PM, Eric V. Smith <eric at trueblade.com> wrote:

> On 8/4/2015 4:05 PM, Mike Miller wrote:
> > Hi,
> >
> > In that message there was a logical step that I don't follow:
> >
> >> For example:
> >> '{a.foo}'.format(a=b[c])
> >>
> >> If we limit f-strings to just what str.format() string expressions can
> >> represent, it would be impossible to represent this with an f-string,
> >> without an intermediate assignment.
> >
> >> For example:
> >> f'{a[2:3]:20d}'
> >>
> >> We need to extract the expression "a[2:3]" and the format spec "20d". I
> >> can't just scan for a colon any more, I've got to actually parse the
> >> expression until I find a "}", ":", or "!" that's not part of the
> >> expression so that I know where it ends.
> >
> > There was a solution to this that came up early in the discussion,
> > moving the identifier only:
> >
> >     f'{x}{y}'           -->  '{}{}'.format(x, y)
> >     f'{x:10}{y[name]}'  -->  '{:10}{[name]}'.format(x, y)
> >
> > I missed the part where this was rejected.  As far as I can tell from
> > your message, it is because it would be hard to parse?  But, it seems no
> > harder than other solutions.  I've whipped up a simple implementation
> > below.
> >
>
> It's rejected because .format treats:
> '{:10}{[name]}'.format(x, y)   -->  format(x, '10') + format(y['name'])
>
> and we (for some definition of "we") would like:
> f'{x:10}{y[name]}'             -->  format(x, '10') + format(y[name])
>
> It's the change from y[name] to y['name'] that Guido rejected for
> f-strings. And I agree: it's unfortunate that str.format works this way.
> It would have been better just to say that the subscripted value must be
> a literal number for str.format, but it's too late for that.
>
> It's not hard to parse either way. All of the machinery exists to use
> either the str.format approach, or the full expression approach.
>
> > Also, Guido sounds supportive of your general process, but to my
> > knowledge has not explicitly called for arbitrary expressions to be
> > included.  Perhaps he could do that, or encourage us to find a more
> > conservative solution?
>
> True, he hasn't definitively stated his approval for arbitrary
> expressions. I think it logically follows from our discussions. But if
> he'd like to rule on it one way or the other before I'm done with the
> PEP draft, that's fine with me. Or, we can just wait for the PEP.
>
> Personally, now that I have a working implementation that I've been
> using, I have to say that full expressions are pretty handy. And while I
> agree you don't want to be putting hyper-complicated dict comprehensions
> with lots of function calls into an f-string, the same can be said of
> many places we allow expressions.
>
> > Sorry to be a pain, but I think this part is important to get right.
>
> No problem. It's all part of the discussion.
>
> Eric.
>
> _______________________________________________
> 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/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150804/7fd7b274/attachment-0001.html>