[stdlib-sig] tkinter package idea

[M.-A. Lemburg]

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.

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.

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.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 20 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611