6 ms·
The issue with f-strings is that they can't be used for i18n. AFAIK, it is impossible to make `_(f"Hello, {name}")` work - at least without a preprocessor or ve
by drdaeman 6y ago
The issue with f-strings is that they can't be used for i18n. AFAIK, it is impossible to make `_(f"Hello, {name}")` work - at least without a preprocessor or very arcane bytecode manipulation magic. This is unlike much uglier but common and well-supported `_("Hello, %(name)s") % {"name": name}`.
In the examples I've used `_` as an alias for a `gettext` call - I believe this is a common practice to do something like `from django.utils.translation import ugettext as _`.
- half-kh-hacker 6y agoNot f-strings, but I am partial to something like: _("Hello, {name}").format(name=name)
- pbsds 6y ago_("Hello, {name}).format(**vars())
- WorldMaker 6y agoA key feature to the recent JS and C# implementations of string interpretation ("template strings") was that both provide a way to pass a template string to a function in a deconstructed form (an array of string parts, and an array of the strings expected to fill their holes). In C# it's a static type expectation (if you cast to a string you get the final formatted string, if you request the FormattableString you get the full deconstructed meta-object) and in JS it's a special function call signature (`` is the template string delimiter and a function that takes the deconstructed parts of a template string is prefixed functionname`example string`). This bit of additional functionality in both JS and C# makes their interpolated strings/template literals extremely useful for i18n (and other uses such as query parameterization and injection attack avoidance). I'm surprised that in comparing the efforts of other languages Python didn't include such functionality in the f-strings PEP. I wonder if such a feature could be added in a non-disruptive way. Maybe a meta-property like a __format_parts__ or something?