How to choose the right GUI toolkit ?

[Dan Lenski]

Hi all,
I'm a recent, belated convert from Perl. I work in a physics lab and
have been using Python to automate a lot of measurement equipment
lately. It works fabulously for this purpose. Recently I've wanted to
start writing GUIs for some of my programs, for data visualization and
to make the programs easier to use for some of my co-workers.

So far I've experimented with two Python GUI toolkits: Tkinter and
PyGTK. I've had some issues with each:

* PyGTK - not very "pythonic", in my opinion. Have to use get_ and
set_ methods rather than properties. Have to write ugly things like
textview.insert (textview.get_e nd_iter(), ...) to append text to a text
buffer. No useful doc strings, which makes experimenting with new
widgets in IPython a huge pain. The toolkit feels very "heavyweigh t".
I don't want to write an XML file and an "action group" just to make a
piddly little menubar with 10 items.

I'm an avid Gnome fan, and love the professionalnes s and completeness
of GTK, but PyGTK seems frustratingly C-like compared to the
wonderfully designed high-level abstractions I've come to love in
Python!

* TkInter - Seems easy to learn, and better for quick "lightweigh t"
GUIs. I wrote a complete working instrument GUI in less than a day of
figuring things out. Not very Pythonic in terms of creating and
modifying widgets. No factory functions to quickly create menu items.
My biggest problem with Tkinter is that it is very unreliable under
Cygwin: programs freeze and slow intermittently and the tkMessageDialog
stock dialog boxes show no visible text.

So, is there another toolkit I should be looking at? Having something
that can run easily on Cygwin and native Windows is a priority so that
I can quickly move programs to new measurement computers. I like GTK a
lot and Tk is growing on me too.. are there any higher-level "wrapper"
toolkits for GTK and Tk?

Thanks for any advice!

Dan Lenski
University of Maryland

[Michael Hobbs]

Steven D'Aprano wrote:

On Fri, 10 Nov 2006 15:18:55 -0600, Michael Hobbs wrote:

>Ron Adam wrote:

>>It is also an outline form that frequently used in written languages. Something
python tries to do, is to be readable as if it were written in plain language
where it is practical to do so. So the colon/outline form makes a certain sense
in that case as well.

That is perhaps the most convincing argument that I've heard so far.
Indeed, I often find myself writing out colons when writing pseudo-code
out on paper. The reason, however, is usually because my indents don't
quite line up as perfectly on paper as they do in an editor. The colons
provide a form of backup separation for when my columns start to get
sloppy. (Natural language is actually filled with such redundancies in
order to compensate for sloppy handwriting.)

Er, natural language pre-dates handwriting by many tens or hundreds of
thousands of years. The redundancy of natural language has many reasons,
but compensating for sloppy handwriting is not one of them.

I was using the term "natural language" in a wider sense, as in spoken
languages, unspoken languages (sign languages), and writing systems. As
far redundancies in writing systems go, it has been estimated that there
is ~50% redundancy in the characters alone. That is, you can usually
determine what a character is even when half of its strokes are removed.
That's not even considering other redundancies such as using a phonetic
alphabet vs. ideographs, or writing the vowels between consonants, which
only started with the Greek alphabet.

>This backup function
obviously isn't needed when a computer is taking care of the layout.

That word you use, "obviously" , I don't think it means what you think it
means. There's nothing obvious about your conclusion to me.

while (this really long expression
(which extends over multiple lines
and contains many statements)
some of which (like this one) contain
nested bracketed terms such as (this
expression here) but like all good
things) it eventually ends
and we can get to the business
of executing the while-block

Compare that to the version with a colon:

while (this really long expression
(which extends over multiple lines
and contains many statements)
some of which (like this one) contain
nested bracketed terms such as (this
expression here) but like all good
things) it eventually ends:
and we can get to the business
of executing the while-block
Arguably, the parser might not find the first version any more difficult
than the second, but I know which one I'd rather read.

I'd rather read neither. Both of them are obviously illegible. As the
saying goes, you can write FORTRAN code in any language. That is, no
language, no matter what its parsing rules, can prevent you from writing
illegible code if you're determined to do so. To me, the second example
is no more legible simply because it contains a colon somewhere. Proper
style would dictate that you make some form of obvious break when
writing a multi-line conditional, no matter which language you're using.
Some possibilities:

while (this really long expression
(which extends over multiple lines
and contains many statements)
some of which (like this one) contain
nested bracketed terms such as (this
expression here) but like all good
things) it eventually ends:

and we can get to the business
of executing the while-block
or

while (this really long expression
(which extends over multiple lines
and contains many statements)
some of which (like this one) contain
nested bracketed terms such as (this
expression here) but like all good
things) it eventually ends:
and we can get to the business
of executing the while-block
or

while (this really long expression
(which extends over multiple lines
and contains many statements)
some of which (like this one) contain
nested bracketed terms such as (this
expression here) but like all good
things) it eventually ends:
#### BODY ####
and we can get to the business
of executing the while-block

>My final argument against the colons is to simply try programming in
Ruby for a while and then come back to Python. I think you'll find that
programming without the colons just simply feels more "natural".

And maybe you're even correct. But one major reason of using the colon is
to make it easier for _inexperienced_ programmers. Your suggestion that
programming in Ruby for a while should be a prerequisite for making Python
easy to read is an interesting one, but not one that many people will
agree with. *wink*

Is Python a cult, where it's considered dangerous to experience the
outside world out of fear that it may corrupt your mind and make you
question all sorts of long-standing edicts?

If you're concerned about coddling inexperienced programmers, maybe you
should join Java cult. I hear that it is much more "safe" ;-)

- Mike

[John Salerno]

Fredrik Lundh wrote:

John Salerno wrote:

>>Anyway, the FAQ answer seems to be a weak argument to me.

I agree. I was expecting something more technical to justify the
colon, not just that it looks better.

yeah, the whole idea of treating programming languages as an interface
between people and computers is really lame. no wonder nobody's using
Python for anything.

</F>

personally, i don't mind the colon and see no need to lose it, but if we
are talking in the realm of aesthetics, it actually seems like it would
be cleaner if it weren't there...sure, at first everyone who is used to
it might feel like something is missing, or the line is "hanging" open,
but overall the less characters, the better, right? isn't that why the
braces are gone?

[Michael Hobbs]

Antoon Pardon wrote:

On 2006-11-11, Steven D'Aprano <st***@REMOVE.T HIS.cybersource .com.auwrote:

>On Fri, 10 Nov 2006 13:16:32 -0600, Michael Hobbs wrote:

>>Yeah, okay, I didn't read through the details of the PEP. I picked a bad
example to illustrate a point that is still true. The FAQ also tries to
argue that it's a Good Thing that join() is a string method, not a list
method. It also tries to argue that there's a good reason that lists are
different than tuples. I don't think it would surprising that many
Python developers don't really buy those arguments either.

Well, as far as I'm concerned, you've just blown your credibility
completely out the water now.

Yes, I'm aware that there are many Python programmers who don't get join()
or lists/tuples, but I'm constantly surprised by that fact. At the risk of
starting another argument, to my mind that's like discovering that there
are professional butchers who don't think that using a sharp knife is a
good idea.

Well I would think that if you would find out that many professional
butchers would think so, you might consider the idea has some merrit.

As they say, insanity is nothing more than having a minority opinion. As
more people take the opposite side, who's left being the crazy one? ;-)

- Mike

[Michael Hobbs]

Georg Brandl wrote:

Ron Adam wrote:

>Michael Hobbs wrote:

>>The same problem that is solved by not having to type parens around the
'if' conditional, a la C and its derivatives. That is, it's unnecessary
typing to no good advantage, IMHO. I was coding in Ruby for several
months and got very comfortable with just typing the if conditional and
hitting return, without any extra syntax. When I came back to Python, I
found that I felt annoyed every time I typed the colon, since it
obviously isn't required. The FAQ says that the colon increases
readability , but I'm skeptical. The indentation seems to provide more
than enough of a visual clue as to where the if conditional ends.

I'm not sure why '\'s are required to do multi-line before the colon.

Special cases aren't special enough to break the rules.

Georg

Eh? So multi-line strings are special enough to create a new syntax,
like, say, triple-quoted strings? Very long expressions aren't special
enough to create a special backslash token to continue the expression on
the next line? Multiple short expressions aren't special enough to
create a special semi-colon token to combine them on a single line?

Programming language design is nothing more than deciding the best way
to deal with special cases. That even includes Lisp.

- Mike

[Michael Hobbs]

Ron Adam wrote:

sk**@pobox.com wrote:

> >>>>I'm not sure why '\'s are required to do multi-line before the colon.
>>>Special cases aren't special enough to break the rules.
>>>>
>>>Georg
>>A bit of a circular answer.
>>>
>>Why the rule? -So not to break the rule?
>>
>You proposed to allow leaving off line continuation '\' only in the
>"if", "for" and "while" headers. This is a special case in my eyes.

RonI wasn't that specific and it was related to Michael's suggestion
Ronthe colon wasn't needed. If the need for '\' was dropped in
Ronmulti-line block headers, then the colon would be required for an
Ronobvious reason.

But \ is used to continue all sorts of statements/expressions, e.g.:

x = a + \
b

not just conditionals.

Skip

Of course, and your point is?

How about if it be ok to continue to use '\' in headers, but it also be ok to
not to? That would be the backward compatible way to change it.

This doesn't answer the question I was asking, are there any situation where it
would cause problems? And if so, that reason would be a good and explicit
reason for not making such a change

To be clear, this is the actual thrust of my argument. It seems
redundant to have *both* line continuations and colons in compound
statements. I've been arguing for the removal of colons, though to be
honest, I'd be content with the opposite approach as well.

- Mike

[Michael Hobbs]

Carsten Haese wrote:

On Sat, 2006-11-11 at 23:18 -0800, Doug wrote:

>Michael Hobbs wrote:

>>I think the colon could be omitted from every type of compound
statement: 'if', 'for', 'def', 'class', whatever. Am I missing anything?

Thanks,
- Mike

It is a very good idea as the colon is technically redundant (not
necessary for parsing, aside from one liners) and actually hurts
readability (and writeability). The "evidence" people cite for the
advantage of using a colon is research done by users of the ABC
language, python's predecessor. They forget that A) that was like 20
years ago,

Research being old does not automatically invalidate it. Old research is
invalidated by newer research that invalidates it.

No, old research does is not automatically invalidated, but
out-of-context research is. I'm sure there's research somewhere proving
that code written in ALL UPPERCASE is preferable, since it makes
punched-cards easier to read by humans. Python 1.0 may have been a nice
language for "newbies", with a lot of similarities to ABC, but there has
been a lot of evolution since then. Sure, it's still very easy to teach
basic Python, but if you're concerned about readability, take a look at
any real-world Python app or library. You'll find it's filled with
things such as "__getattr_ _", "__repr__", "__nonzero_ _", and
"super(MyCl ass, self).__init__( )". Hardly newbie stuff.

I think waving the banner of ABC simplicity in the context of Py3K is
about as applicable as complaining that an RSS aggregator isn't written
in assembly. (An RSS aggregator is so far beyond being CPU-bound that
it's pointless to argue which language it should be written in.)

- Mike

[Michael Hobbs]

Ron Adam wrote:

LOL, of course it would. I would expect that too after a suitable amount of
'brain washing', oops, I mean training and conditioning. ;-)

Trust me, my brain is quite filthy and doesn't wash easily. I do
appreciate aesthetics, which is why still stay with Python, even after
programming in Ruby for several months. I've used Java/C/C++ for years,
yet I make no complaint about the lack of static typing in Python. Even
so, I'd like to think that I know a good thing when I see it.

The point is what is more natural to "read" with a minimum amount of
explanation. I would think for most people who are learning programming for the
first time, it is things that resemble things they already know. Such as
outlining with colons.

Leaving the colon out probably would feel more natural for writing once you get
used to it. After all it is a bit less typing. But I don't think it would be
the most readable choice for most people. It's probably a trade off,
readability vs writability. Another python development guideline is to favor
readability over writability on the presumption we tend to write code once, but
read code many times.

Not to repeat myself from an earlier post, but any pretense that
Python's primary objective is readability went out the window with the
invention of such constructs as "__del__", "__repr__", and
"super(MyCl ass, self).__init__( )". There are obviously other goals to
the language's development that inspired these constructs and override
the priority of readability.

Here's an alternative test. Write a program to remove all the end of line
colons from pythons library and then write another separate program to put them
back in. Will it miss any? will it pass the python test suite?

I just may take you up on that. ;-) Not for a few days, though. Not
enough time right now.

- Mike

[Ron Adam]

Michael Hobbs wrote:

Ron Adam wrote:

>LOL, of course it would. I would expect that too after a suitable amount of
'brain washing', oops, I mean training and conditioning. ;-)

Trust me, my brain is quite filthy and doesn't wash easily. I do
appreciate aesthetics, which is why still stay with Python, even after
programming in Ruby for several months. I've used Java/C/C++ for years,
yet I make no complaint about the lack of static typing in Python. Even
so, I'd like to think that I know a good thing when I see it.

I find if I approach things on a learning basis and always presume there are
things I still don't know. I then tend to get much more help and support than
if I approach things on a 'I'm right/your wrong' basis. Also, if I do turn out
to have a point a view that is not exactly right, it is then much easier for me
to take a new position or even the reverse position and move on.

Not to repeat myself from an earlier post, but any pretense that
Python's primary objective is readability went out the window with the
invention of such constructs as "__del__", "__repr__", and
"super(MyCl ass, self).__init__( )". There are obviously other goals to
the language's development that inspired these constructs and override
the priority of readability.

No one said (that I know of) that readability is *the primary objective*. But
it is a very important guideline.

>Here's an alternative test. Write a program to remove all the end of line
colons from pythons library and then write another separate program to put them
back in. Will it miss any? will it pass the python test suite?

I just may take you up on that. ;-) Not for a few days, though. Not
enough time right now.

- Mike

I believe you will find that exercise much more difficult than it seems, but I
may be wrong. Good luck if you try it, and let me know how it goes.

Ron

[Michael Hobbs]

Ron Adam wrote:

Michael Hobbs wrote:

>Ron Adam wrote:

>>LOL, of course it would. I would expect that too after a suitable amount of
'brain washing', oops, I mean training and conditioning. ;-)

Trust me, my brain is quite filthy and doesn't wash easily. I do
appreciate aesthetics, which is why still stay with Python, even after
programming in Ruby for several months. I've used Java/C/C++ for years,
yet I make no complaint about the lack of static typing in Python. Even
so, I'd like to think that I know a good thing when I see it.

I find if I approach things on a learning basis and always presume there are
things I still don't know. I then tend to get much more help and support than
if I approach things on a 'I'm right/your wrong' basis. Also, if I do turn out
to have a point a view that is not exactly right, it is then much easier for me
to take a new position or even the reverse position and move on.

To clarify my position, I'm not intentionally being contradictory. In
fact, when I first posed my question, I asked if anyone had a good
reason for why the redundancy should continue to exist. Expecting to get
a nice grammatical counter-example, the only viable answer that anyone
could come up with is the FAQ answer that it improves readability. Since
then, I've been fighting my point that the colon really doesn't improve
readability all that much.

In the end, I have to admit that I really couldn't give a flying frog if
the colon is there or not. It's just a colon, after all. I *was* hoping
that I could convince someone to honestly think about it and consider if
the colon is really that noticeable. But so far, the only response that
I've received is that there's that ABC study somewhere and that settles
that.

- Mike

[Ben Finney]

John Salerno <jo******@NOSPA Mgmail.comwrite s:

personally, i don't mind the colon and see no need to lose it, but
if we are talking in the realm of aesthetics, it actually seems like
it would be cleaner if it weren't there...sure, at first everyone
who is used to it might feel like something is missing, or the line
is "hanging" open, but overall the less characters, the better,
right? isn't that why the braces are gone?

No. "The fewer characters, the better" is not right. Such absolutes
are to be avoided.

Sometimes, as in the case of omitting block-enclosing braces, removing
characters results in better readability. Other times, as in the case
of explicit names for objects, *more* characters results in better
readability -- but only up to a point.

Readability doesn't vary directly or inversely with the number of
characters, even though it is affected when they change.

--
\ "I bought a self learning record to learn Spanish. I turned it |
`\ on and went to sleep; the record got stuck. The next day I |
_o__) could only stutter in Spanish." -- Steven Wright |
Ben Finney