GUI:-please answer want to learn GUI programming in python , how should i proceed.
steve+comp.lang.python at pearwood.info
Sun Dec 15 18:01:53 CET 2013
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>
>> 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.
More information about the Python-list