On Fri, Sep 18, 2020 at 08:05:27AM -0000, Joseph Perez wrote:
Steven D'Aprano wrote:
I'm not aware of many refactoring tools for Python at all, [...] I don't know how well IDEs like VisualStudio and PyCharm do refactoring.
This help me to understand your point of view.
But if I consider your proposition, it's evident that a simple comment `# IDE:refactor` would not be enough for IDE. Because a string is full of words and several of them could matchs the symbols of your code;
I see your point, but I don't think it's a large problem in practice. As Ricky and Wes have pointed out, IDE refactoring tools are already able to look inside not just f-strings but regular strings too. If your point is a practical problem, it is *already* a practical problem for refactoring tools. How do they deal with this?
The point is, whatever techniques they use, whatever they need, we shouldn't jump into adding new language features to the language because they *could* be useful for IDEs and refactoring tools. Find out from the writers of the software what they actually need, not just what you guess they might use, and then we can have a better discussion as to whether that should go into the language or not.
By the way, there is (as far as I know) no comment standardisation in Python, they are specific to the tools which use them. See how many docstring standard we have; Both Pycharm and Black have their own comment directive to toggle formatting on/off; when mypy and flake8 find an issue in your code, you have to put # type: ignore # noqa… How could an approach using comment be promising?
That is why I am suggesting that tool users should start cooperating on a standard for directives.