[stdlib-sig] tkinter package idea

[Brett Cannon]

On Feb 20, 2008 2:27 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-02-20 11:05, Brett Cannon wrote:
> > While I would rather have a tk package (heck, I would be fine with
> > ditching Tkinter entirely, but I really don't see that happening), but
> > the Tkinter name is so wide-spread I don't think that is reasonable.
>
> Hey, it's Py3k...
>
> > So here is my current thinking:
> >
> > Tkinter -> tkinter.__init__
> > Tix -> tkinter.tix
> > turtle -> tkinter.turtle
> > tkSimpleDialog -> tkinter.simpledialog
> > tkMessageBox -> tkinter.messagebox
> > tkFont -> tkinter.font
> > tkFileDialog -> tkinter.filedialog
> > Tkdnd -> tkinter.dnd
> > Tkconstants -> tkinter.constants
> > tkCommonDialog -> tkinter.commondialog
> > tkColorChooser -> tkinter.colorchooser
> > SimpleDialog -> tkinter.simpledialog
> > ScrolledText ->tkinter.scrolledtext
> > FixTk -> tkinter._fix
> > FileDialog -> tkinter.filedialog
> > Dialog -> tkinter.dialog
> > Canvas -> tkinter.canvas
> >
> > I know Guido has said he doesn't like stuffing a bunch of stuff into
> > the __init__ of  a package, but considering none of the other modules
> > are worth anything without the main Tkinter module anyway I don't see
> > any issues here.
>
> I usually put all the package top-level code into a separate
> module with the same name as the package.
>
> __init__.py then imports all the necessary symbols from that
> module.
>

Right. tkinter.__init__ would just import * from _tkinter anyway.

> These are problems I've had with putting code into __init__.py:
>
> * if there's a bug in __init__.py it's impossible to load
>   sub-modules/packages; if you import the code from another
>   module, you can wrap that into try-except and still get
>   access to the sub-modules
>
> * a user will typically not look into __init__.py to find
>   code
>
>
> If you name the package "tk" you could name the main module
> "inter" and then end up with "tk.inter" which again resembles
> the widespread Tkinter name.
>

FIne by me. What do other people think?

> I'd much rather see Tkinter and all the other bits be split
> from the core and placed into a separate distribution, but the
> IDLE fans would probably not like that.

Perhaps its time to move IDLE out of the core and into its own
project. idlefork seemed to do fine when it was a separate project on
SF. I know it has been cute to have an IDE included with Python, but
we can also just make it an easy download as well to continue to have
a simple IDE available for new programmers to use.

-Brett