My credentials for this are that I re-worked str.format in Jython quite
extensively, and I followed the design of f-strings a bit when they were
introduced, but I haven't used them to write anything.
On 29/03/2018 00:48, Tim Peters wrote:
> [Tim Delaney <timothy.c.delaney at gmail.com>]
>> ...
>> I also assumed (not having actually used an f-string) that all its
>> formatting arguments were evaluated before formatting.
> It's a string - it doesn't have "arguments" as such. For example:
> def f(a, b, n):
> return f"{a+b:0{n}b}" # the leading "f" makes it an f-string
>
Agreed "argument" is the wrong word, but so is "string". It's an
expression returning a string, in which a, b and n are free variables. I
think we can understand it best as a string-display
(https://docs.python.org/3/reference/expressions.html#list-displays), or
a sort of eval() call.
The difference Serhiy identifies emerges (I think) because in the
conventional interpretation of a format call, the arguments of format
are evaluated left-to right (all of them) and then formatted in the
order references are encountered to these values in a tuple or
dictionary. In an f-string expressions are evaluated as they are
encountered. A more testing example is therefore perhaps:
'{1} {0}'.format(a(), b()) # E1
f'{b()}{a()}' # E2
I think I would be very surprised to find b called before a in E1
because of the general contract on the meaning of method calls. I'm
assuming that's what an AST-based optimisation would do? There's no
reason in E2 to call them in any other order than b then a and the
documentation tells me they are.
But do I expect a() to be called before the results of b() are
formatted? In E1 I definitely expect that. In E2 I don't think I'd be
surprised either way. Forced to guess, I would guess that b() would be
formatted and in the output buffer before a() was called, since it gives
the implementation fewer things to remember. Then I hope I would not
depend on this guesswork. Strictly-speaking the documentation doesn't
say when the result is formatted in relation to the evaluation of other
expressions, so there is permission for Serhiy's idea #2.
I think the (internal) AST change implied in Serhiy's idea #1 is the
price one has to pay *if* one insists on optimising str.format().
str.format just a method like any other. The reasons would have to be
very strong to give it special-case semantics. I agree that the cases
are rare in which one would notice a difference. (Mostly I think it
would be a surprise during debugging.) But I think users should be able
to rely on the semantics of call. Easier optimisation doesn't seem to me
a strong enough argument.
This leaves me at:
1: +1
2a, 2b: +0
3: -1
Jeff Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180329/9fa050f6/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4