views:

489

answers:

2

Now don't get me wrong, I'm not exactly a Python fan, but when you see a Tk directory inside of the python directory you kinda expect... Well Python. And yeah, I get that Tk came from TCL, but if I had to write a TCL to use Tk, I'd forget TK existed and use a completely different tool box. (The popularity of this combination completely eludes me.)

Expecting to see a relatively readable language like Python, and finding TCL is like walking in on your grandma naked. It's just visually painful.

I haven't drank the cool-aid when it comes to Python, but I use for simple task that I don't want to bother with C or C++ on and maybe if I want some for quick and dirty text processing. It just seems like a cruel joke to put TCL examples in the Python distribution.

Is there an equivalent package that includes those examples written in Python?

Edit: I guess this also kinda begs the question is Tk the best option for GUI dev in Python?

+2  A: 

Perhaps you should start by looking at the Python Tkinter documentation here and the Tkinter wiki here.

And where are you seeing Tcl examples? Are you looking at a Tcl library supplied with Python perhaps?

Ned Deily
Those are probably good ideas. I'll have to check which directory I was poking around in when I get to work tomorrow.
NoMoreZealots
I think your right. I must have been feeling a little Lexdisic when I asked this question.
NoMoreZealots
+3  A: 

There are no Tcl examples in Python's official distribution; whatever distro you're using must have bundled them on its own volition.

IMHO, Tk's only real advantage by now is the convenience that comes from having it bundled with Python. I was criticized for covering it in "Python in a Nutshell", but I stand by that decision because it is still "the" bundled toolkit, after all. But if you want something better and don't mind taking a tiny amount of inconvenience to procure it (and possibly to bundle it with apps you distribute), there are other excellent choices.

PyQt (if you can stand the GPL license or pay for the commercial one) and wxPython are IMHO currently superior offerings for cross-platform GUI apps (though you'll have to work to bundle them with py2exe or PyInstaller if you want to distribute a stand-alone app) and other packages are excellent if you don't care about cross-platform distribution or have specialized needs (e.g. pyui -- while now a general-purpose UI toolkit -- for simple UIs for games if you're using PyGame or PyOpenGL anyway).

Alex Martelli
It's an installation I have on another machine. I looked on this one and the files aren't here. I recall it was a 2.5 install on that machine (Win98), where this is a 2.4 here (WinXP). But I wouldn't expect that to matter.
NoMoreZealots
"superior offerings" is certainly in the eye of the beholder. I've been doing wxPython for the past several months (with a decade of Tk experience behind me) and it's definitely not superior to Tk IMHO. It does some things better of course, and many things not as well. It's remarkably buggy and under-documented compared to Tk, though in practice the bugs are usually not showstoppers.
Bryan Oakley
@Bryan, API-wise I agree, my preference for APIs is PyQt first, Tkinter second, wxPython last; look-and-feel-wise, though, Tkinter is currently last, wx and Qt vying for top spot. But hey, I did say IMHO;-).
Alex Martelli