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.

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.

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

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

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)

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

does the rule document why the fixes are unsafe?

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.

fair enough

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.

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

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