Eric V. Smith <e...@trueblade.com> added the comment:
I've put some more thought in to this, and this is the best I can come up with,
using today's Python.
The basic idea is that you have a function _f(), which takes a normal (non-f)
string. It does a lookup to find the translated string (again, a non-fstring),
turns that into an f-string, then compiles it and returns the code object. Then
the caller evals the returned code object to convert it to a string.
The ugly part, of course, is the eval. You can't just say:
_f("{val}")
you have to say:
eval(_f("{val}"))
You can't reduce this to a single function call: the eval() has to take place
right here. It is possible to play games with stack frames, but that doesn't
always work (see PEP 498 for details, where it talks about locals() and
globals(), which is part of the same problem).
But I don't see much choice. Since a translated f-string can do anything (like
f'{subprocess.run("script to rm all files")'), I'm not sure it's the eval
that's the worst thing here. The translated text absolutely has to be trusted:
that's the worst thing. Even an eval_fstring(), that only understood how to
exec code objects that are f-strings, would still be exposed to arbitrary
expressions and side effects in the translated strings.
The advantage of compiling it and caching is that you get most of the
performance advantages of f-strings, after the first time a string is used. The
code generation still has to happen, though. It's just the parsing that's being
saved. I can't say how significant that is.
See the sample code in the attached file.
----------
Added file: https://bugs.python.org/file48504/f-string-gettext.py
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36310>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
