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

[Steven D'Aprano]

On Sun, 15 Dec 2013 14:53:45 +0000, Grant Edwards wrote:

> On 2013-12-14, Steven D'Aprano <steve+comp.lang.python at pearwood.info>
> wrote:
> 
>> But more seriously, 100% seriously in fact, I think that you'll find
>> that *every* GUI framework for Python ships with an entirely different
>> language under the hood, usually C.
> 
> Name one GUI framework that ships with a C implementation.

Er, all of them? I daresay that Tcl itself eventually calls graphics 
routines written in C. There's not that many languages that commonly get 
used for low-level graphics routines, but C is one of them.

If you mean, ships with a C *compiler*, or even a C interpreter, then no, 
probably not. But it wouldn't surprise me if some of those GUI frameworks 
are powerful enough to count as mini-languages in their own right.


>> Even if the top level of the framework is written in Python, the
>> underlying graphics routines used for drawing controls and windows will
>> surely not be.
> 
> You seem to be equating "was compiled from" with "includes an
> implemenation of".  Do you say that CPython "ships with C"?

Well, when you take my comments out of their context, that does seem to 
be a totally stupid thing to say. But in context, it's only *mostly* 
stupid, and mostly stupid means a little bit sensible *wink*

The context was a complaint, or at least expression of surprise, that 
Python use Tcl for a GUI, this being contrasted with (paraphrasing the 
legions of people who have expressed surprise about this in the past) 
"some hypothetical GUI written in Python". But in practice, it won't be 
written in Python, it will be likely written in C or some other low-level 
language with some interface to Python. The main difference between this 
hypothetical "Python GUI" and Tcl is that Tcl is a Turing-complete 
interpreter which lives in it's own process. 

[Aside: I wonder how many other GUI toolkits are Turing complete?]

As I stated earlier, this is just the Interpreter design pattern, with 
the minor complication that the domain specific language happens to be an 
existing language, Tcl, with an interpreter that usually runs in a 
separate process, instead of some mini-language running inside Python.

So I don't see anything surprising about Tkinter (or for that matter, 
Ruby and it's bindings to Tcl/Tk). Maybe it's because I'm used to Unix/
Linux systems, where it is common for tools that execute in one 
interpreter to call other tools which execute in a different interpreter. 
E.g. a shell script which calls a Ruby script which calls some command 
which happens to be written in Python. Python, after all, was originally 
invented to be a glue language, and I don't really see anything weird 
about Python delegating work to Tcl any more than I see anything strange 
about IronPython delegating work to the .Net runtime.



-- 
Steven