fix: support block-level wrong-import-position pragma suppression #10590

emmanuel-ferdman · 2025-09-24T23:29:02Z

Type of Changes

	Type
✓	🐛 Bug fix

Description

Previously, a # pylint: disable=wrong-import-position pragma on a non-import statement would incorrectly suppress wrong-import-position messages for all subsequent import statements in the module. This violated the expected behavior where single-line pragmas should only affect their own line. The fix changes the message enablement check from using the first non-import node's line number to using the current import node's line number, ensuring proper pragma isolation.

Example:

import logging

logger = logging.getLogger()  # pylint: disable=wrong-import-position
import os  # This should trigger wrong-import-position
import sys  # This should trigger wrong-import-position

Expected Output:

Before: No wrong-import-position messages (incorrect behavior)
After: wrong-import-position messages for both import os and import sys (correct behavior)

Closes #10589

codecov · 2025-09-24T23:43:53Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.97%. Comparing base (68ab16f) to head (7fb7b18).
⚠️ Report is 71 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10590      +/-   ##
==========================================
+ Coverage   95.95%   95.97%   +0.01%     
==========================================
  Files         176      176              
  Lines       19455    19537      +82     
==========================================
+ Hits        18668    18750      +82     
  Misses        787      787

Files with missing lines	Coverage Δ
pylint/checkers/imports.py	`94.96% <100.00%> (+0.08%)`	⬆️

... and 30 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Pierre-Sassoulas

I'm wondering if the 'right way to fix this' isn't to return uninferable in astroid instead. Because it's possible that a function validly return an empty list.

emmanuel-ferdman · 2025-09-25T08:25:57Z

@Pierre-Sassoulas Should it be fixed in the astroid library itself or using an astroid hook in pylint library?

Pierre-Sassoulas · 2025-09-25T09:57:53Z

Astroid itself, we're the same maintainers and 99% of astroid user are also pylint users :)

Signed-off-by: Emmanuel Ferdman <[email protected]>

for more information, see https://pre-commit.ci

emmanuel-ferdman · 2025-09-25T19:33:59Z

@Pierre-Sassoulas thanks for the guidance! I opened a PR in the astroid repo for this issue. Since this PR is already open, I also included a fix for another pylint issue. Apologies for the force push 🙌

DanielNoord

Thanks for the PR!

In the future it would be better to open a new one as that makes communication scoped a bit better. We can still continue with this one though :)

DanielNoord · 2025-09-26T12:52:45Z

tests/functional/w/wrong_import_position_pragma_scope.py

+import json  # pylint: disable=wrong-import-position
+
+# Test that subsequent imports are not affected by the pragma above
+import csv  # [wrong-import-position]
+import re  # [wrong-import-position]


I'm not sure if this is the correct behaviour, or at least should be considered a breaking change?

The test you're changing above seems to explicitly test for this case:
A previous disable should also count for subsequent imports.

@Pierre-Sassoulas What do you think?

Ha, yes, we reviewed independently but I think we said the same thing..

@Pierre-Sassoulas You approved, but this question still stands I guess? We're now actively removing support for behaviour for which we had a test. I'm not sure why we added this behaviour in the first place, but considering we are changing behaviour isn't this a breaking change?

Right, we didn't say the same thing after all. It seems we can't have an easy implementation of both "disable on a statement" and "any disable prevent all further wrong-import-position" so there's a decision to take here. And we might have to do the hard implementation, especially since I don't think isort or ruff deal with intertwined statements in imports (?).

Current PR does:

The fix changes the message enablement check from using the first non-import node's line number to using the current import node's line number, ensuring proper pragma isolation.

Perhaps we can it to:

The fix changes the message enablement check from no longer working on non-import statements for this message. A pragma will disable from the current import statement until further statements, ensuring proper pragma isolation.

Pierre-Sassoulas · 2025-09-26T13:03:17Z

pylint/checkers/imports.py

-            if self.linter.is_message_enabled(
-                "wrong-import-position", self._first_non_import_node.fromlineno
-            ):
+            if self.linter.is_message_enabled("wrong-import-position", node.fromlineno):


Instinctively I would say the fix need to be a lot more complex than that. If one line is disabled it means not only that the message shouldn't be raised for it but also that other line should not raise if the only issue for them it the disabled line.

i.e. the expected is

import a import b import c

import b # [wrong-import-position] import a # [wrong-import-position] import c

import b # pylint: disable=wrong-import-position import a import c

import b # pylint: disable=wrong-import-position import c # [wrong-import-position] import a # [wrong-import-position]

Tbf, I don't think we should sweat other this, maybe we need to abandon the pylint disable system for this specific error message, and take the isort/ruff "I" disable into account, or drop the message entirely, or integrate ruff plus autofix and drop isort, or integrate both ruff and isort... I don't see a fix for this being super impactful in the mid term.

I don't fully understand your comment, and I think taking into accounts other tools setting is bit too much work for @emmanuel-ferdman 😅

@emmanuel-ferdman Do you think we can fix your issue while still keeping the behaviour as being tested in the test? I agree that a disable on a non-import makes no sense, but perhaps we can fix it with a smaller scope?

What I mean is that the effort to fix this at all is not worth it as we have ruff and isort for reordering import, having working disable in pylint or coordinating multiple tools that check this message does not bring a lot of value imo. (Maybe we can even remove the check entirely for 4.0)

@DanielNoord @Pierre-Sassoulas Thanks for the feedback 🙌
From issue #10589 and seeing that other pylint rules are line-based, I assumed this was a bug. But I understand that wrong-import-position might be different since it's about import ordering patterns. What should we do here? I'm happy to try and implement whatever you think is best.

Sorry for marking an issue as ready for PR when clearly it wasn't well specified @emmanuel-ferdman. Or thank you for making the fix and making us realize what actually fixing this bug imply. I think we should close because there's probably better use for your time. Right now I'm more and more convinced that we should either drop isort and wrong-import-position (import time at startup could make this a big change for users) or add ruff (using ruff and isort as optional dependencies instead of isort as mandatory dependency would open a world of possibilities once the wrong-import-position proof of concept is validated). In all case this mean this fix is not going to be used much. Need some other maintainers opinion about it and it's probably an idea for pylint 5.0 anyway (that I should open an issue for if Daniel don't think it's trash).

I agree with removing the dependency on isort.

It fails logical to let those concerns be dealt with by a separate tool with its own configuration and/or ignores. Wondering what other maintainers think.

ruck94301 · 2025-09-26T21:03:42Z

@Pierre-Sassoulas, you gave 4 examples above (importing a, b, & c).
Those seem like wrong-import-order C0411, not wrong-import-position C0413.
I mean, I think they are actually not the expected. But if you change to the pragma and expected messages to wrong-import-order, yes that's the expected.

The original bug report is about wrong-import-position, which maybe doesn't require sorting & other complexities?

At any rate, thanks for taking my report seriously, I appreciate that! :)

Pierre-Sassoulas · 2025-09-27T07:46:00Z

Ha, indeed you're right, my bad. Well the fix LGTM as is after a second take. I'm going to create an issue for the unrelated discussion.

ruck94301 · 2025-09-29T16:03:13Z

Sorry to risk additional confusion. I will try hard to be clear.
The issue in this bug is regarding C0413 wrong-import-position, not C0411 wrong-import-order. That has already been clarified.

However, during the above conversation, I agreed with the expectations of a different condition, C0411 wrong-import-order, as shown with importing a, b, & c in different orders.

import os  # [wrong-import-order]
import logging  # [wrong-import-order]
import sys

which seemed reasonable. But OTOH, this also seems reasonable to the user:

import os
import logging  # [wrong-import-order]
import sys

So, which is actually implemented? Easy to check...
Neither. C0411 (in pylint 3.3.7) doesn't seem to verify the sort order of the libraries within the three "families"-- at least the standard libraries family. Because I'm seeing no C0411 on the following.

import os
import logging
import sys

I DO get C0411 when I, for example, import a third-party lib in the wrong place.

import os
import requests
import logging  # [wrong-import-order]
import sys  # [wrong-import-order]

Maybe C0411 doesn't attempt to validate the "alphabetical" sort order recommendation of PEP 8, and concerns itself only with whether the three sets of imports are correctly organized per PEP 8 like (1) standard lib imports, (2) related 3rd party lib imports (3) Local application/library specific imports.
So even though I cannot see how this is relevant to C0413, I wanted to clarify C0411 existing behavior in 3.3.7. Hope this helps. LMK if you think I'm misunderstanding something.
Best Regards,
John

emmanuel-ferdman · 2025-10-17T11:59:01Z

@Pierre-Sassoulas @DanielNoord Thanks for the review! Just checking what the final decision is - should this be merged, closed, or is any further action needed?

Pierre-Sassoulas · 2025-10-17T16:32:59Z

Sorry for the delay @emmanuel-ferdman we released 4.0 :) did you consider @ruck94301 's point ? What do you think ?

emmanuel-ferdman · 2025-10-19T14:18:06Z

@Pierre-Sassoulas I tested all the examples @ruck94301 mentioned. They were just clarifying how C0411 works separately from C0413. The current PR changes fulfill what's needed - the pragma now works line-by-line for C0413 as expected, and C0411 is unaffected. Ready to review/merge from my side.

Pierre-Sassoulas

I'm not sure the fix in its current form is a net positive, what's your opinion @DanielNoord ?

tests/functional/d/disable_wrong_import_position.py

Pierre-Sassoulas · 2025-10-19T14:50:05Z

tests/functional/d/disable_wrong_import_position.py

 CONSTANT = True  # pylint: disable=wrong-import-position

-import sys
+import sys  # [wrong-import-position]


I think disabling on the line that create the issue instead of the multiple imports that are affected, made sense and was instinctive. I would test for this:

Suggested change

import sys # [wrong-import-position]

import os

import sys

CONSTANT = False # pylint: disable=wrong-import-position

import time

SOME_OTHER_CONSTANT = True

import logging # [wrong-import-position]

I think I understand now - You suggest putting the pragma on the non-import line that breaks the import block, so it suppresses the following imports until the next non-import. Inline disables on the import line should still work. My new changes follow this logic - please let me know if that what you meant.

DanielNoord

This still seems like a breaking change?

Note that I won't have a lot of internet access in the coming weeks. So don't block this on my review.

jacobtylerwalls · 2025-10-19T16:19:53Z

This still seems like a breaking change?

We're removing a dubious feature. Maybe we can avoid backporting in that case. It was added in #1337 without much discussion.

Signed-off-by: Emmanuel Ferdman <[email protected]>

for more information, see https://pre-commit.ci

emmanuel-ferdman · 2025-10-19T23:03:10Z

For now, I followed @Pierre-Sassoulas’s suggestion: a pragma on the non-import line that breaks the import block suppresses the following imports until the next non-import. Inline disables on the import line still work as before. Please let me know what you think.

Example:

import os
import sys

# First non-import with pragma - suppresses following imports
CONSTANT1 = "value1"  # pylint: disable=wrong-import-position
import json
import csv

# Second non-import without pragma - imports after this should be flagged
CONSTANT2 = "value2"
import logging

# Third non-import with pragma - suppresses following imports again
CONSTANT3 = "value3"  # pylint: disable=wrong-import-position
import pathlib
import random

# Fourth non-import without pragma - import after this should be flagged
CONSTANT4 = "value4"
import re

Output:

input.py:14:0: C0413: Import "import logging" should be placed at the top of the module (wrong-import-position)
input.py:23:0: C0413: Import "import re" should be placed at the top of the module (wrong-import-position)

Signed-off-by: Emmanuel Ferdman <[email protected]>

github-actions · 2025-10-19T23:42:53Z

🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉

This comment was generated for commit 7fb7b18

This comment has been minimized.

Sign in to view

Pierre-Sassoulas reviewed Sep 25, 2025

View reviewed changes

fix: scope wrong-import-position pragma to specific line only

8cace41

Signed-off-by: Emmanuel Ferdman <[email protected]>

emmanuel-ferdman force-pushed the main branch from 28128d9 to 8cace41 Compare September 25, 2025 19:20

emmanuel-ferdman changed the title ~~fix: avoid false positive unbalanced-tuple-unpacking for cross-module function calls~~ fix: scope wrong-import-position pragma to specific line only Sep 25, 2025

fix: scope wrong-import-position pragma to specific line only

a7e937a

Signed-off-by: Emmanuel Ferdman <[email protected]>

emmanuel-ferdman force-pushed the main branch from dd9aafb to a7e937a Compare September 25, 2025 19:29

[pre-commit.ci] auto fixes from pre-commit.com hooks

f957d35

for more information, see https://pre-commit.ci

This comment has been minimized.

Sign in to view

DanielNoord reviewed Sep 26, 2025

View reviewed changes

Pierre-Sassoulas reviewed Sep 26, 2025

View reviewed changes

Pierre-Sassoulas added the Needs decision 🔒 Needs a decision before implemention or rejection label Sep 26, 2025

Pierre-Sassoulas added this to the 4.0.0 milestone Sep 26, 2025

Pierre-Sassoulas approved these changes Sep 27, 2025

View reviewed changes

Pierre-Sassoulas added Bug 🪲 backport maintenance/4.0.x and removed Needs decision 🔒 Needs a decision before implemention or rejection labels Sep 27, 2025

Pierre-Sassoulas modified the milestones: 4.0.0, 3.3.9 Sep 27, 2025

jacobtylerwalls modified the milestones: 3.3.9, 4.0.1 Oct 5, 2025

Pierre-Sassoulas removed the backport maintenance/4.0.x label Oct 11, 2025

Pierre-Sassoulas mentioned this pull request Oct 11, 2025

Removal of mandatory isort dependency for import position check #10637

Open

Pierre-Sassoulas modified the milestones: 4.0.1, 4.0.2 Oct 15, 2025

Pierre-Sassoulas added the Needs decision 🔒 Needs a decision before implemention or rejection label Oct 17, 2025

Pierre-Sassoulas requested changes Oct 19, 2025

View reviewed changes

DanielNoord reviewed Oct 19, 2025

View reviewed changes

Support block-level wrong-import-position pragma suppression

1015d06

Signed-off-by: Emmanuel Ferdman <[email protected]>

emmanuel-ferdman changed the title ~~fix: scope wrong-import-position pragma to specific line only~~ fix: support block-level wrong-import-position pragma suppression Oct 19, 2025

[pre-commit.ci] auto fixes from pre-commit.com hooks

4c56438

for more information, see https://pre-commit.ci

fix: support block-level wrong-import-position pragma suppression

7fb7b18

Signed-off-by: Emmanuel Ferdman <[email protected]>

jacobtylerwalls modified the milestones: 4.0.2, 4.0.3 Oct 20, 2025

-import sys  # [wrong-import-position]
+import os
+import sys
+CONSTANT = False # pylint: disable=wrong-import-position
+import time
+SOME_OTHER_CONSTANT = True
+import logging  # [wrong-import-position]

Uh oh!

fix: support block-level wrong-import-position pragma suppression #10590

Are you sure you want to change the base?

fix: support block-level wrong-import-position pragma suppression #10590

Conversation

emmanuel-ferdman commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Type of Changes

Description

Uh oh!

codecov bot commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

This comment has been minimized.

Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

Uh oh!

emmanuel-ferdman commented Sep 25, 2025

Uh oh!

Pierre-Sassoulas commented Sep 25, 2025

Uh oh!

emmanuel-ferdman commented Sep 25, 2025

Uh oh!

This comment has been minimized.

DanielNoord left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Pierre-Sassoulas Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ruck94301 commented Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Pierre-Sassoulas commented Sep 27, 2025

Uh oh!

ruck94301 commented Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

emmanuel-ferdman commented Oct 17, 2025

Uh oh!

Pierre-Sassoulas commented Oct 17, 2025

Uh oh!

emmanuel-ferdman commented Oct 19, 2025

Uh oh!

Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DanielNoord left a comment

Choose a reason for hiding this comment

Uh oh!

jacobtylerwalls commented Oct 19, 2025

Uh oh!

emmanuel-ferdman commented Oct 19, 2025

emmanuel-ferdman commented Sep 24, 2025 •

edited

Loading

codecov bot commented Sep 24, 2025 •

edited

Loading

Pierre-Sassoulas Sep 26, 2025 •

edited

Loading

ruck94301 commented Sep 26, 2025 •

edited

Loading

ruck94301 commented Sep 29, 2025 •

edited

Loading