There are a number of refactoring tools for Python.
From :


* PyCharm -

Editor plugins
* vim -
* emacs -

* bowler -
* libcst -
* undebt -
* redbaron -


"Support f"literal {string} interpolation" (PEP-498, Python 3.6)" (fixed)

"Rename symbol misses symbols in formatted strings f"{foo}" (fixed because rope fixed it)

"Can Bowler rename the variable in the format string literals?"

On Thu, Sep 17, 2020 at 8:27 PM Steven D'Aprano <> wrote:
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.

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.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: