3 ms·
There is the expectation of IDLE, no? Isn't that a tkinter product?
by smitty1e 7y ago
There is the expectation of IDLE, no? Isn't that a tkinter product?
- sigzero 7y agoIt is.
- tanilama 7y agoBut 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.
- detaro 7y agoDepends, 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)
- dragonwriter 7y agoThough 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.
- tanilama 7y agoTaking 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.
- analog31 7y agoThis 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.