On Thu, Sep 17, 2020 at 11:47:03PM -0000, Joseph Perez wrote:
Thus `f"{:a + b}" == "a + b"`.
That can already be done by just *not* using a f-string. This looks like a case of "when the only tool you have is a hammer, everything looks like a nail". If you don't want a string literal to be evaluated, don't put it inside a f-string. There is no need to have a extra token inside f-strings to turn off evaluation. We already have a way to not evaluate strings.
Like "normal" formatted expression, it would be handled by IDEs, especially for refactoring. The difference with "normal" formatted expression is that the expression would not be evaluated.
I'm not aware of many refactoring tools for Python *at all*, the wiki still lists BicycleRepairman which hasn't been updated for seven years. https://wiki.python.org/moin/AutomatedRefactoringTools I don't know how well IDEs like VisualStudio and PyCharm do refactoring, but I would think that if you wanted to refactor strings, a more promising approach would be a tagged comment rather than f-strings:
```python def foo(bar: int): if bar != 42: # If `bar` is renamed, error message will be renamed too by the IDE raise ValueError(f"{:bar} is not 42") ```
def foo(bar: int): if bar != 42: # IDE:refactor raise ValueError("bar is not 42") tells the IDE that it's okay to refactor inside the string literal in the following line. I doubt this feature exists today, but if you expect linters to learn to refactor f-strings they could learn to refactor regular strings too. It seems to me that rather than modifying Python to create special syntax for no-ops to be used as directives for the benefit of IDEs, it would be better for IDEs to get together and work on a common syntax for directives which can be included in regular comments. -- Steve