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

[Chris Angelico]

On Tue, Dec 17, 2013 at 9:06 AM, Christian Gollwitzer <auriocus at gmx.de> wrote:
> Let the flame war begin!

I'll try to avoid flamage :)

> 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.

Ah, okay. Don't take gitk as representative. Got it. Unfortunately
there are quite a few languages that I've experienced from, really,
only one program that I've tried to modify (Scheme almost falls in
that category too - all I've ever used it for is LilyPond scripting,
and not much of that), and I'm aware that's not really a fair look at
the language.

>> 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.

Yeah. Like I said,

>> Can live with that

. But my rule of thumb with bash scripts is: If it exceeds a page or
two in length, it's probably time it got rewritten in an application
language. When a program is the size of gitk (>10KLOC), the benefits
relating to interactive use (as you mention below) become less
significant, and benefits relating to discoverability of the more
obscure features become more significant.

> 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.

Okay. Now, how am I to figure out where this command comes from? It's
not a host command (typing "mc" at the bash prompt comes up failure),
and it's not defined in the script itself (at least, I can't find
"proc mc" anywhere); is it a Tcl built-in? Where do I start looking?

(Yes, I'm aware this is a problem in any language. I'm not now raising
a point in the Python vs Tcl debate, I'm just asking out of
curiosity.)

> 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:

Yeah, that's nice for the interactive interpreter... but I already
have bash for that, and Python's not far off. I've used interactive
Pike and REXX interpreters, which are both more demanding than Python
(in terms of syntax requirements and such), so I'm perfectly happy
with Python; but if you're used to something even lighter, then sure,
use something that lets you type almost nothing. No problem. I just
think that - as mentioned above - a ten thousand line program should
be aiming more at maintainability than ease of manual typing.

> * 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.

Cool. Not enough for me to choose the language unless I really REALLY
needed that feature, but there was one time in my programming career
when that was true, so we'll count that a win.

> * 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.

Nice, though Python's threading and/or multiprocessing can do 90% of
what people want. Side point: What about Tk? Can you (a) run separate
GUI threads for separate windows? (b) manipulate widgets created by
another thread?

> * 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.

Never really needed this, but for the people who do, I'm sure that's a
fairly big deal.

So there definitely are some advantages that Tcl has over Python. Put
against them is a superior object model, a large corpus of first-class
object types (dict, set, list, etc[1]), and a syntax that more clearly
differentiates names and strings without making variable references
look like a lot more than they are.

Huge room in the world for both languages to exist and thrive.

ChrisA

[1] What is an etc() in Python?