tkinter: stdlib but not really

[Akuli]

While tkinter is technically stdlib, it feels like a third-party package in a couple ways:

• It's not always distributed with Python. The default Python installation on most linux distros includes all of the stdlib except tkinter, because that way python doesn't need to depend on Tcl/Tk.
• I want to use the latest possible tkinter stubs instead of waiting several months for the next mypy release. I don't know how other typed tkinter people feel about this. @melassa and @Hawk777, what do you think?

We could consider moving tkinter stubs from stdlib/ to stubs/. This would create a types-tkinter project on pypi that is auto-updated when pull requests are merged, even though you aren't supposed to pip install tkinter.

[JukkaL]

This sounds reasonable to me. Tkinter somehow feels like a separate entity from the rest of the stdlib in my mind, even though it's included with CPython. It also has larger stubs than most stdlib packages, so it's perhaps likely that users would like to update tham. Though I rarely use tkinter, so take my opinion with a grain of salt.

[JelleZijlstra]

My main worry is that this will be confusing to users who might not understand that tkinter is treated specially by typing. If we make this change, how should we communicate it to users?

[JukkaL]

Mypy would likely generate an error and suggest installing types-tkinter if the stubs are missing, but the code being type checked imports it. We'd also mention this in the mypy release notes. I think that this would be self-explanatory. Tools that ship the entire typeshed shouldn't be affected at all.

[srittau]

I am not a big fan of this, after all tkinter is part of the stdlib. A similar rationale could be used for quite a few other stdlib modules, e.g. asyncio, statistics, curses, turtle, ssl. Why should they be part of the stdlib if ssl is not? But this begs another question: Could the stdlib be distributed separately from type checkers, with type checkers declaring a dependency?

[Hawk777]

I don’t have a strong opinion. I don’t write a lot of Python these days, much less with tkinter—I use it occasionally when a project calls for it, not on a day-to-day basis.

[Akuli]

Here's another idea: why not auto-upload types-foo packages of all stdlib modules? That way a project doesn't have to bundle typeshed in a git submodule just to use some fix in typeshed. Type checkers wouldn't have to suggest installing those automatically, because the stdlib bundled with the type checker is usually good enough.

[Avasam]

We have some precedence for stubs that can't be installed in a classic manner (ie using pip): https://github.com/python/typeshed/tree/main/stubs/gdb

Can tkinter even be installed and updated separately from Python ? (in a way that affects stubs)

If not, then I say keep it in stdlib, and focus the discussion to #5835 instead. (I've had similar needs with setuptools/distutils and having to wait for my stdlib distutils updates to be live)

If yes, is that also the case for

a few other stdlib modules, e.g. asyncio, statistics, curses, turtle, ssl.

---

Mypy would likely generate an error and suggest installing types-tkinter if the stubs are missing, but the code being type checked imports it. We'd also mention this in the mypy release notes. I think that this would be self-explanatory. Tools that ship the entire typeshed shouldn't be affected at all.

Also this.

[hauntsaninja]

I'd vote to close this. I think mypy releases are a little more regular than they were four years ago and tkinter stubs are much improved and more stable. I'm not aware of mixing and matching tkinter and python versions