Enable Ruff flake8-import-conventions (ICN)

[Avasam]

Ref #13295
flake8-import-conventions (ICN)

We were already using the import alias convention for numpy, tensorflow, matplotlib, pandas. Not for tkinter though (so @Akuli thoughts?)

[Avasam]

Here's a request to add this alias convention to the default aliases: astral-sh/ruff#17028

[Akuli]

I'm personally not a big fan of the import tkinter as tk convention, but it is quite popular, and I'm fine with merging this if other maintainers think this is a good idea.

That said, I don't see a strong reason to enforcing this rule in typeshed. For example, I don't see why it is a problem that networkx stubs do import numpy. Aliasing it to np makes sense if your project is full of numpy, but networkx stubs are not.

[Avasam]

stdlib/tkinter/ttk.pyi's Style.tk was also causing issues for mypy:

class Style:
    master: Incomplete
    tk: _tkinter.TkappType
    def __init__(self, master: tk.Misc | None = None) -> None: ...

https://github.com/python/typeshed/actions/runs/14118275408/job/39553451357?pr=13731#step:6:17

Hard to justify using a different alias in that one place when it's all within tkinter's own stub anyway.

[Akuli]

I wonder if you could still use extend-aliases and set "tkinter"="tkinter" to disable that one.

[Avasam]

That actually works! Even if we don't end up using these rules, I opened a request to document that behaviour: astral-sh/ruff#17097

[JelleZijlstra]

I don't think this is worth it; there's no real point for us in using these rules.

[AlexWaygood]

do these get autofixed? If so then I don't mind them -- there is value in consistency, even if it's not very much value.

If they don't get autofixed then I definitely agree then they're just too annoying to be worth it

[Avasam]

do these get autofixed?

The changes here are all autofixes. But they're "unsafe" autofixes. So you have to explicitly run ruff check --fix --unsafe-fixes or use editor hint actions. It won't be fixed by editors on save, pre-commit hooks, CI, etc. unless we explicitly allow this one with extend-safe-fixes (like we do UP036)

[github-actions]

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

[AlexWaygood]

does the rule document why the fixes are unsafe?

[JelleZijlstra]

I feel even if it's autofixable, the fact that we need to add a noqa rule in one case means the costs are higher than the benefits.

[AlexWaygood]

fair enough

[Avasam]

does the rule document why the fixes are unsafe?

It doesn't, but i think it's clear that it changes that available and used symbol names, which could result in a clash or unexpected dynamic result (like from a getattr or and analysis tool). Feel free to add it to the doc if you want.

[Avasam]

Looks like there's a consensus on "not worth automating".

[AlexWaygood]

In general Ruff's aim to explicitly document why any given fix is considered unsafe. We obviously fall a long way short of that aim right now! It looks like it's one of the rules listed in astral-sh/ruff#15584