Skip to content

fix typing_extensions auto-import#1754

Merged
DetachHead merged 1 commit intoDetachHead:mainfrom
beauxq:fix-extensions-group
Mar 18, 2026
Merged

fix typing_extensions auto-import#1754
DetachHead merged 1 commit intoDetachHead:mainfrom
beauxq:fix-extensions-group

Conversation

@beauxq
Copy link
Copy Markdown
Contributor

@beauxq beauxq commented Mar 18, 2026

typeshed treats typing_extensions as stdlib
So when the auto-import inserts it, it inserts it in the stdlib section.
This fixes it to put it in the 3rd party section.

before:

from typing_extensions import override
from unittest import TestCase

after:

from unittest import TestCase

from typing_extensions import override

was grouped with stdlib, now grouped with 3rd party
@github-actions
Copy link
Copy Markdown
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Copy link
Copy Markdown
Owner

@DetachHead DetachHead left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm on the fence about this. on one hand typing_extensions can be considered first-party since it's an official package maintained in the @python org. but since it doesn't actually come with python i can also understand why you'd want it to be considered third-party like every other pypi package.

it looks like ruff's unsorted-imports rule also considers it third party, so i'm happy to do the same.

@DetachHead DetachHead merged commit c777e52 into DetachHead:main Mar 18, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants