If Tkinter goes, then Python is dead to me. I use Python for small dep-free single file GUIs for small projects meant to be used by people who have Python installed but can't be bothered to go through an installation checklist. Tkinter is great for that and is the only reason I bother using Python for anything.

"pip install --user -r requirements.txt" is not a terribly odious "installation checklist", and I don't think it's the start of a slippery slope towards one either.

If you're worried about people not RTFM when using your projects, you could always start your scripts with the standard try/import/except wrapper around the required package, and tell them to run pip install when it's not found--or (and this is a terrible idea) run it in a subprocess for them.

Asking my users to use the command line is odious.

Pardon me, but why wouldnt you be able to just run an old python if tkinter came out of the stdlib, or even just package it with whatever you are distributing?

The point was that it’s much easier to distribute a single file app than it is to “correctly” distribute a full app with dependencies bundled.

Could you use cython to accomplish this? I personally haven’t used it, but looking at some examples it looks really straightforward.

Tkinter is awesome, I hope it isn't jettisoned. I haven't found anything that easy to use with a similar Canvas.

Being able to add items to a canvas, attach callbacks to them - without tracking them yourself, setting up the infrastructure for indexes, bounding boxes, all that stuff - I haven't found anything else as easy as Tkinter's Canvas.

If there is something better, I'd love to hear about it.

Come over to the PyCairo side of The Force! It will drawn you in and fill your path with beautiful pixels.

https://cairographics.org/pycairo/

You do have a good point about Tk's canvas easy input handling though, which is something Cairo doesn't do. It's just an immediate mode drawing api like PostScript's rendering model or html canvas 2d context.

You can pass a pycairo context into C++ Python extensions, and they can go to town with it quite efficiently.

https://github.com/SimHacker/micropolis/tree/master/Micropol...

https://github.com/SimHacker/micropolis/blob/master/Micropol...

I love Tkinter, but I could accept letting it be an installable package rather than built-in. I can certainly see its size and complexity being a burden on smaller installations. I think making "pip install tkinter" be bulletproof would go a long way. You're not going to start using Tkinter unless you're reading a tutorial anyway.

There's always going to be a good debate about which batteries should be included. I'd almost put numpy ahead of Tkinter, but maybe that reflects my bias for scientific programming.

There is the expectation of IDLE, no? Isn't that a tkinter product?

This question suggests a criterion for what batteries should be included, which is platform dependence. What both Tkinter and IDLE do, is ensure that there is a basic GUI library, and a code editor, that can run on any platform.

Coming from Visual Basic, and similar things (HyperCard, Turbo Pascal), being able to run a program with GUI on both Windows and Linux with no code changes was nothing short of amazing to me. So maybe that's one way to draw the line with batteries, namely to make it so a beginner can get started with Python, with no regrets about which OS they're using. This requires some out-of-box hardware abstraction, where they keyboard, mouse, and display, all effectively count as hardware.

But this only can't justify that tkinter being part of the STANDARD library.

Taking tkinter out of the standard library won't stop IDLE being built with it, if they chose to do so.

Though OS packaging may frequently obscure this because OS packagers break up the language distribution, Idle is part of the language distribution, so (unless you expand the distribution to include core packages outside of stdlib, as with Ruby’s gemification effort) it has to be built with stdlib alone. Tkinter, therefore, needs to be part of stdlib.

Taking IDLE outside of the standard distribution and make a separate download link for it, isn't in anyway going to hurt Python at this point.

Just move tkinter like what they do with typing package is good enough to address everyone's need.

Depends, do you consider IDLE part of the standard library? (it's separated in many distributions, but documented in the standard library documentation, so it's a bit mixed, but it's probably okay to not consider it part of the library, but just the standard distribution)

It is.

Tkinter is used by matplotlib's show() function. Without tkinter, you would somehow need to replace it with some other platform independent gui library.

If it weren't in the stdlib, could it not be installed as a depdencency when you install matplotlib?

Why does it need to go?

It uses a non trivial amount of resources for (nearly) every python install. Therefore if it isnt of substantial use then it should be removed to free those resources

It does, but it's hardly an egregious amount (my 3.7 install on Win10 has it at 800Kb... though I guess tcl takes up 10MiB =P). For reference, the built in venv module (which I never use cause I'm all about that virtualenv life) is 1MB. The python tests are 20MB, and that ships by default on every python installation.

Like if you were in a resource constrained situation, you would be customizing your python install anyways (if nothing else, getting rid of the docs, the tests, maybe stripping out all but the compiled code...).

Maybe just use kitdll instead of a full blown Tcl/Tk distro, to provide the dependency, that would shrink the size a lot.

http://kitcreator.rkeene.org/fossil/wiki?name=KitDLL