There are a number of refactoring tools for Python.
>From https://github.com/beat-no/roper#alternatives :

```rst
Alternatives
============

IDEs
----
* PyCharm -
https://www.jetbrains.com/help/pycharm/refactoring-source-code.html

Editor plugins
--------------
* vim - https://github.com/python-rope/ropevim
* emacs - https://github.com/python-rope/ropemacs

Libraries
---------
* bowler - https://pybowler.io/
* libcst - https://libcst.readthedocs.io/en/latest/
* undebt - https://github.com/Yelp/undebt
* redbaron - http://redbaron.pycqa.org/en/latest/

Resources
=========
* https://github.com/python-rope/rope
* https://realpython.com/python-refactoring/
```

"Support f"literal {string} interpolation" (PEP-498, Python 3.6)" (fixed)
https://github.com/python-rope/rope/issues/226

"Rename symbol misses symbols in formatted strings f"{foo}" (fixed because
rope fixed it)
https://github.com/microsoft/vscode-python/issues/187

"Can Bowler rename the variable in the format string literals?"
https://github.com/facebookincubator/Bowler/issues/87

On Thu, Sep 17, 2020 at 8:27 PM Steven D'Aprano <[email protected]> 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.
>
> 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
> _______________________________________________
> Python-ideas mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/4ERAXMGP4QIPR55ZC5MA3D32MSJIYQPB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ZINNFP7JMUAVFCI36FNZ7HEA74YPSMSF/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to