Open jacobeatsspam opened 4 years ago
isort does a pretty good job in formatting and can easily be chained in a workflow with yapf. isort also comes with a set of own sensible configurations and is already integrated in IDEs such as VSCode. Of course, one would be expected to call both tools, which can be a hassle. Still, I would not include isort capabilities in yapf.
Another argument against yapf sorting import is, that yapf does not alter the syntax of a file. Consider this ugly example:
from a_very_long_or_indented_module_name_yada_yad import \
long_argument_1, \
long_argument_2, \
long_argument_3
isort would produce
from a_very_long_or_indented_module_name_yada_yad import (
long_argument_1, long_argument_2, long_argument_3)
But yapf wouldn't touch the line as it includes a backslash, and it would have to change the syntax.
Of course, one would be expected to call both tools, which can be a hassle
Which is exactly the point of this issue; not running two tools, unless the integration is trivial and not per-user (as your vscode suggestion is).
But yapf wouldn't touch the line as it includes a backslash, and it would have to change the syntax.
We have the power to update code to handle imports. It's not written in stone (meant as a joke, not sarcasm).
YAPF is meant to reformat code, and to do it as "safely" as possible . I realize that people want it to sort imports (a very common request) and/or add/remove brackets, etc., but those activities reduce the safety factor. The import order does matter for some modules, as changing the order may affect the semantics of the program. It could be said that modifying brackets is safer to change, but I can't guarantee that.
Given that these are common requests, I've considered adding lib2to3 style "fixers", where people can add their own plugins to modify the code as they wish. An alternative solution may be to allow "pre" and "post" commands to be run (for systems which don't allow for piping commands).
Thoughts?
@gwelymernans Great points and I respect the preference to stay out of this. To that end, I like both of these ideas, but think it would be best to prioritize pre and post commands. Thanks.
Given that these are common requests, I've considered adding lib2to3 style "fixers", where people can add their own plugins to modify the code as they wish. An alternative solution may be to allow "pre" and "post" commands to be run (for systems which don't allow for piping commands).
Thoughts?
I came here to this issue because I am used to this feature in clang-format. I think, for C++ and C apply the same as for Python: Reordering includes can crash the entire compilation process but likely does not. So maybe you can introduce a knob that is off by default and if people are activating it and it crashes something they can just prevent reformatting on just those parts with additional comments. And comments on those parts make sense anyway since reordering should not crash anything.
Regarding the plugins: I fear that, if yapf has such plugins, either projects add the same formatting code to their codebases ever and ever again or they have a distribution problem: Then, a developer not only needs yapf but also these 2 plugins additionally.
Or may it be possible to ship a bunch of plugins as default? With that, they are seperated within this codebase but always belong to yapf itself.
For some reason I have to develop with Python 3.6.8, recently isort stopped supporting this version of Python even though it worked adequately. Now isort just doesn't work, showing the message: "The isort server crashed 5 times in the last 3 minutes. The server will not be restarted.". I would also like to see a feature to sort imports in yapf. (google translate)
Problem
I encounter holy wars about import sorting even though ordering is clear in PEP8.
Please, I don't want to use another tool (isort) when this aligns with the vision of this project. Or I'd like the ability to trigger an arbitrary chain of other formatters, through yapf, so devs aren't expected to configure too many things when picking up a new repo.
Many thanks for this project!
Related Issues
203
385