Closed pkatseas closed 6 years ago
I think your style is different to the edited one, in that edited specifies that the import x
and from x ...
should be grouped together. It is very possible to create your own style using the extension functionality, which will solve your issue. (Note that I202
is new to releases >= 0.14).
I am conflicted between this plugin having many custom styles or a few opinionated ones. For a while now I've not accepted additional styles as the extensions allowed for any custom one. Which styles would you include? (I also wonder if #99 would make the difference mute)
Hi @pgjones, thanks for your reply.
To clarify, my comment was indeed about EDITED codebases (and using the EDITED style).
I have checked the test example of the style and it indeed looks like the imports there do not reflect the second case I've mentioned in my previous comment, i.e. the one that causes the I202
s.
How would you propose to address that and add compatibility for both cases (assuming it is easily feasible)?
I think your best bet is to create an extension for your particular custom style. Alternatively you could configure flake8 to ignore I202 errors.
It would be weird for the edited
style here not to reflect the actual style at @EDITD, though.
Ah, I missed that this was the actual edited use case, Thanks. I has assumed the edited style was the split version.
ok, what do you make of #131?
@pgjones branch fixes all this
In master, will release soon.
Thanks for your work on this @pgjones, and apologies for the delayed response, unplugged holidays got in the way. :)
Hey there, we're using this plugin for linting imports at EDITED and have noticed unwanted
I202
s with recent versions.Our style would normally allow for both of the following cases:
and
with the difference here being the empty line between the
import
andfrom
parts of an import section.It looks like the second case is no longer allowed under
I202
though. We have several codebases that already follow that kind of style though, and are getting a fair amount ofI202
s that we're actually OK with.For the time being, we can pin to a version of the plugin that does not flag those up, so it's not a pressing issue. Do you however have any suggestions on how to proceed here to avoid remaining pinned to a version permanently? If there are any pointers on necessary changes to allow for a bit more flexibility around this, I could provide a PR.