[issue37341] str.format and f-string divergence

Eric V. Smith added the comment: I've fixed the bpo number in Misc/NEWS.d/3.8.0b1.rst. Thanks for reporting that. -- ___ Python tracker ___ ___

[issue37341] str.format and f-string divergence

Tim Hatch added the comment: ok, I suppose it's just documentation then. -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python ___ Python tracker _

[issue37341] str.format and f-string divergence

Brett Cannon added the comment: I also agree with Eric's assessment. Thanks for the idea, Tim, but I'm closing this as rejected. -- nosy: +brett.cannon resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker

[issue37341] str.format and f-string divergence

Raymond Hettinger added the comment: I concur with Eric. This differences are there by design. The technical and security reasons are both compelling. -- nosy: +rhettinger ___ Python tracker _

[issue37341] str.format and f-string divergence

Eric V. Smith added the comment: > str.format, string.Formatter, and the _string module can only > parse literal keys, not expressions, despite appearing to take the > same syntax as f-strings. I'm happy to contribute code to change > this, but unsure if it's considered a bug or feature (now t

[issue37341] str.format and f-string divergence

New submission from Tim Hatch : TL;DR f"{x+2}" and f"{x=}" do something sensible. "{x+2}".format(x=1) and "{x=}".format(x=1) raise KeyError. f"{0.1}" and "{0.1}".format(...) are different. Having had a feature request to be able to codemod f-strings[1] and just learning about issue36817[2] la