-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pybabel should raise an error when it encounters f-strings #715
Comments
Hi, I can send in a pull request for this. Will be done in the next few days. |
I've recently falled into this one, as per python 3.9 I was moving to using fstrings and for one of the files it fails with error. With the previous version of the file, using regular "%s" substitutions it worked, but when running pyupgrade over the code and getting some fstrings instead, it started failing. It would also be great to identify the line that caused the failure to better trace and debug those |
Just to clarify, while it should probably produce a reasonable warning, rather than an exception, the problem in your code is the fact that you were formatting a string before sending it for translation. i.e. |
Since f-strings are rendered at import time, pybabel needs some extra contextual information from the string's location in order to import the string properly. This is a known issue in pybabel: python-babel/babel#715
Inspired by code from @a-angeles13, thanks to him! Add .format() fixes needed for pybabel. See python-babel/babel#715
F-strings are a bad idea for translations, because they cause Babel to crash when collecting strings to translate: python-babel/babel#715 But even if we replaced f-strings with new-style string interpolation such as `_("{foo}").format(foo=foo)`, it's still a bad idea, because a wrong translation can crash Ihatemoney at runtime with a KeyError. Instead, we must really use old-style python formatting since they are well supported in Babel. Wrong translations that mess with string interpolations will cause Babel to give an error when compiling translation files, which is exactly what we want.
F-strings are a bad idea for translations, because they cause Babel to crash when collecting strings to translate: python-babel/babel#715 But even if we replaced f-strings with new-style string interpolation such as `_("{foo}").format(foo=foo)`, it's still a bad idea, because a wrong translation can crash Ihatemoney at runtime with a KeyError. Instead, we must really use old-style python formatting since they are well supported in Babel. Wrong translations that mess with string interpolations will cause Babel to give an error when compiling translation files, which is exactly what we want.
F-strings are a bad idea for translations, because they cause Babel to crash when collecting strings to translate: python-babel/babel#715 But even if we replaced f-strings with new-style string interpolation such as `_("{foo}").format(foo=foo)`, it's still a bad idea, because a wrong translation can crash Ihatemoney at runtime with a KeyError. Instead, we must really use old-style python formatting since they are well supported in Babel. Wrong translations that mess with string interpolations will cause Babel to give an error when compiling translation files, which is exactly what we want.
F-strings are a bad idea for translations, because they cause Babel to crash when collecting strings to translate: python-babel/babel#715 But even if we replaced f-strings with new-style string interpolation such as `_("{foo}").format(foo=foo)`, it's still a bad idea, because a wrong translation can crash Ihatemoney at runtime with a KeyError. Instead, we must really use old-style python formatting since they are well supported in Babel. Wrong translations that mess with string interpolations will cause Babel to give an error when compiling translation files, which is exactly what we want.
F-strings are a bad idea for translations, because they cause Babel to crash when collecting strings to translate: python-babel/babel#715 But even if we replaced f-strings with new-style string interpolation such as `_("{foo}").format(foo=foo)`, it's still a bad idea, because a wrong translation can crash Ihatemoney at runtime with a KeyError. Instead, we must really use old-style python formatting since they are well supported in Babel. Wrong translations that mess with string interpolations will cause Babel to give an error when compiling translation files, which is exactly what we want.
F-strings are a bad idea for translations, because they cause Babel to crash when collecting strings to translate: python-babel/babel#715 But even if we replaced f-strings with new-style string interpolation such as `_("{foo}").format(foo=foo)`, it's still a bad idea, because a wrong translation can crash Ihatemoney at runtime with a KeyError. Instead, we must really use old-style python formatting since they are well supported in Babel. Wrong translations that mess with string interpolations will cause Babel to give an error when compiling translation files, which is exactly what we want.
To test this patch I used .. and checked the diff of the `messages.pot` file:: $ ./manage pyenv.cmd pybabel extract -F babel.cfg \ -o ./searx/translations/messages.pot searx/ $ git diff ./searx/translations/messages.pot ---- hint from @dalf: f-string are not supported [1] but there is no error [2]. searx/translations/messages.pot [1] python-babel/babel#594 [2] python-babel/babel#715 Closes: searxng#3412 Signed-off-by: Markus Heiser <[email protected]>
To test this patch I used .. and checked the diff of the `messages.pot` file:: $ ./manage pyenv.cmd pybabel extract -F babel.cfg \ -o ./searx/translations/messages.pot searx/ $ git diff ./searx/translations/messages.pot ---- hint from @dalf: f-string are not supported [1] but there is no error [2]. [1] python-babel/babel#594 [2] python-babel/babel#715 Closes: searxng#3412 Signed-off-by: Markus Heiser <[email protected]>
To test this patch I used .. and checked the diff of the `messages.pot` file:: $ ./manage pyenv.cmd pybabel extract -F babel.cfg \ -o ./searx/translations/messages.pot searx/ $ git diff ./searx/translations/messages.pot ---- hint from @dalf: f-string are not supported [1] but there is no error [2]. [1] python-babel/babel#594 [2] python-babel/babel#715 Closes: #3412 Signed-off-by: Markus Heiser <[email protected]>
To test this patch I used .. and checked the diff of the `messages.pot` file:: $ ./manage pyenv.cmd pybabel extract -F babel.cfg \ -o ./searx/translations/messages.pot searx/ $ git diff ./searx/translations/messages.pot ---- hint from @dalf: f-string are not supported [1] but there is no error [2]. [1] python-babel/babel#594 [2] python-babel/babel#715 Closes: searxng#3412 Signed-off-by: Markus Heiser <[email protected]>
I mistakenly put something like that in my code:
and Babel fails (as in it crashes with an exception) to extract strings from this file. The reason why it crashes is that the extract_python function relies on eval(token_code) to obtain the string from its source code representation. While this is legitimate in general, it does not work for f-strings (evaluation will almost certainly crash due to missing variables).
I understand that including f-strings inside the _() function is a mistake, I think Babel should warn the user about the incorrect usage instead of simply crashing. This can be easily fixed by simply wrapping the offending eval() call into a try/except block:
It still accepts f-strings with no interpolation (which is a bad style, but do not cause any damage).
The text was updated successfully, but these errors were encountered: