Describe isort's multi_line_output setting #109
Conversation
Jamim
requested review from
a-feld,
c24t,
carlosalberto,
lzchen,
Oberon00,
reyang and
toumorokoshi
as code owners
|
Related: #36, #95 (comment). |
Jamim
force-pushed
the
feature/update-isort-settings
branch
from
5f20641
to
5154805
Compare
| @@ -64,8 +64,7 @@ | |||
| from contextlib import contextmanager | |||
| import typing | |||
|
|
|||
| from opentelemetry import loader | |||
| from opentelemetry import types | |||
| from opentelemetry import loader, types | |||
There was a problem hiding this comment.
Please don't import multiple modules in a single line (other names are fine, but modules should be one per line).
There was a problem hiding this comment.
I was wondering if we could lint this, but I presume not an easy to figure out what's a module and and object here?
There was a problem hiding this comment.
@toumorokoshi Since you approved the PR but made this comment, I'm not sure what's your opinion on such imports? Do you prefer importing multiple submodules on the same line or each on their own line.
Ad linters: I think pylint knows quite a bit about the meaning of these names. There is no check against it though.
There was a problem hiding this comment.
My opinion isn't strong enough for me to argue the point, but I actually prefer multiple per line. My personal favorite way to refer to an import is Rust syntax, which enables a lot of flexibility with a visually intuitive ident-as-namespace:
https://doc.rust-lang.org/reference/items/use-declarations.html
I think for those who don't use an ide, importing modules exclusively is really helpful. It makes it easy to see what belongs to a module vs what is a local reference:
foo = Foo()
other_object = other_module.Bar()
Once I know it's referenced locally or imported, I then make the determination to go to the top of the file, or to search for the next reference. But I use the go-to-definition functionality of my ide, and so the organization doesn't affect me either away.
The only thing I really dislike is star imports. But I think most people agree on that.
There was a problem hiding this comment.
@Oberon00 it looks like the only way to use isort consistently with black is to allow grouped imports for module names.
|
Would it be a good idea to add |
|
@mauriciovasquezbernal That sounds very useful but should be a separate PR. |
These changes follow up the "Fix and improve tests for Python != 3.7" PR. The multi_line_output was already set to 3 in the "Add initial black formatting" PR, so after rebasing to master this commit contains only comment that describes a magic number from the isort configuration file. Corresponding PR: - open-telemetry#109 Related discussions: - open-telemetry#95 (comment) - open-telemetry#95 (comment)
Jamim
force-pushed
the
feature/update-isort-settings
branch
from
5154805
to
eaf0118
Compare
Jamim
changed the title
|
Hi there, |
These changes follow up the "Fix and improve tests for Python != 3.7" PR. The multi_line_output was already set to 3 in the "Add initial black formatting" PR, so after rebasing to master this commit contains only comment that describes a magic number from the isort configuration file. Corresponding PR: - open-telemetry/opentelemetry-python#109 Related discussions: - open-telemetry/opentelemetry-python#95 (comment) - open-telemetry/opentelemetry-python#95 (comment)
Hello,
These changes follow up #95.
The
multi_line_outputwas already set to3in the Add initial black formatting PR, so after rebasing tomasterthis commit contains only comment that describes a magic number from theisortconfiguration file.Related discussions: