GUI:-please answer want to learn GUI programming in python , how should i proceed.

Christian Gollwitzer auriocus at
Mon Dec 16 23:06:01 CET 2013

Let the flame war begin!
Am 16.12.13 17:10, schrieb Chris Angelico:
> Here's the Tcl procedure that I tweaked. This is from gitk; I find the
> word diff not all that useful, but a character diff at times is very
> useful. I haven't found a way to configure the word diff regex through
> gitk's options, so I tweaked it in the source code.
> proc getblobdiffs {ids} {
>      global blobdifffd diffids env
>      global diffinhdr treediffs
>      global diffcontext
>      global ignorespace
>      global worddiff
>      global limitdiffs vfilelimit curview
>      global diffencoding targetline diffnparents
>      global git_version currdiffsubmod
> .....

 > }

I'm a long time Tcl developer who has just picked up Python recently; so 
my view is tinted from the other side.

First off, gitk is a huge unstructured mess. You are not obliged to 
write programs like this in Tcl, at least not today. All these global 
statements give already a hint, that this is a procedural thing. Think 
of Python, where classes are stripped. Tcl has object oriented 
frameworks for years. If you use Snit, e.g., all those globals are not 
needed because they are really instance variables.

> First off, everything's done with commands, rather than assignment
> ("set diffinhdr 0"), which is very shell-style and not very
> programming-style.

This is just syntax and purely a matter of taste.

> Can live with that, though even shells can use
> equals signs for simplicity. Similarly, the shell style of adorning
> variable usage feels messy. There are string literals, some of which
> contain interpolated variables; there are dollar-sign adorned
> variables; and then there are other words. What are the other words?
> Are they implicit strings (as they would be in, say, bash)?

Yes, they are, and it doesn't feel strange if you are used to it. Tcl's 
syntax rules are very compact. Tclers see this as an advantage.

> Secondly, what does this do?
>      if {$worddiff ne [mc "Line diff"]}
> I *think* it means 'if $worddiff is not equal to "Line diff" (this
> code is executed for the options "Markup words" and "Color words", but
> what's the mc do?

It does command substitution (indeed the brackets [] do) and is one of 
the key concepts of Tcl. mc is probably the command from msgcat which 
translates i18n strings. Complaining about these basic things is like 
complaining about indentation in Python.

> This is where, IMO, Python tends to be a lot clearer. It's easy to see
> what's an object and what's a method on it, and every bare word is
> either a local name or a standard built-in name. I'm sure Tcl's a
> great language, but I'd rather not have to drop out of Python into it
> if I can help it. :)

Python has some advantages over Tcl. To name a few, references, list 
comprehensions, real classes, clean module support, extensive extensions 
such as matplotlib/scipy. But Tcl also has some strengths.

First off, the syntax is quite flexible, and so things like list 
comprehensions[1] or classes[2] can be implemented in Tcl itself. 
Second, it's great at interactive use because at a command prompt, you 
don't want to type all those () call operators, "quotes" and obey 
indentation just to get a simple loop running. Third, its implementation 
features a few unique things:

* Stubs. Compile a C extension against 8.1 and load it into 8.6. This 
actually works. 8.1 was nearly 15 years ago!

* Safe interpreters. Sometimes requested here for Python, you can create 
a slave interpreter in Tcl that is restricted and cannot do disk I/O, 
has limited execution time etc. You can precisely control which commands 
are passed on to the slave.

* Interpreters in threads. There is no GIL, Tcl interpreters are thread 
safe and more than one can coexist in a process and run concurrently. 
This is accessible from script level through the Threads package.

* Very easy deployment: Starkits/Tclkits bundle an interpreter within a 
single executable. Similar to what pyinstaller does. But in my 
experience, it's much easier to pack all dependencies into a starkit 
than it is with pyinstaller. You can get a rather full-fledged 
interpreter with GUI support into a few megabytes, and I've never seen 
it fail.

Happy flaming,



More information about the Python-list mailing list