Is there a list of supported preprocessor directives or compiler directives supported by CPython and other tools?
- from __future__ import ... - __debug__ https://docs.python.org/3/library/constants.html#__debug__ - encoding https://www.python.org/dev/peps/pep-0263/#defining-the-encoding # coding=<encoding name> # -*- coding: <encoding name> -*- # vim: set fileencoding=<encoding name> : ^[ \t\f]*#.*?coding[:=][ \t]*([-_.a-zA-Z0-9]+) - # noqa: - https://flake8.pycqa.org/en/latest/user/violations.html - # flake8: noqa https://docs.python.org/3/distutils/apiref.html#distutils.ccompiler.CCompiler.preprocess https://docs.python.org/3/distutils/setupscript.html#preprocessor-options https://github.com/interpreters/pypreprocessor#syntax https://en.wikipedia.org/wiki/Directive_(programming) : > In computer programming, a directive or pragma (from "pragmatic") is a language construct that specifies how a compiler (or other translator) should process its input. Directives are not part of the grammar of a programming language, and may vary from compiler to compiler. They can be processed by a preprocessor to specify compiler behavior, or function as a form of in-band parameterization. > > In some cases directives specify global behavior, while in other cases they only affect a local section, such as a block of programming code. In some cases, such as some C programs, directives are optional compiler hints, and may be ignored, but normally they are prescriptive, and must be followed. However, a directive does not perform any action in the language itself, but rather only a change in the behavior of the compiler. > > This term could be used to refer to proprietary third party tags and commands (or markup) embedded in code that result in additional executable processing that extend the existing compiler, assembler and language constructs present in the development environment. The term "directive" is also applied in a variety of ways that are similar to the term command. On Fri, Sep 18, 2020 at 6:06 AM Steven D'Aprano <st...@pearwood.info> wrote: > 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. > > -- > Steve > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/BRIOEQMEP7DAYEANMCJ56HNECI2XMQU5/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RWWG2ZWAGMQ2ERBE33P6EB3OUNN6SM7L/ Code of Conduct: http://python.org/psf/codeofconduct/
