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

[Robert Kern]

Michael Hobbs wrote:

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.

Empirical usability research carries a lot of weight. Certainly more so than
projection of personal preferences.

But for what it's worth, my personal preference is that having the colon is more
readable. Yours isn't. That's fine. Debating on that basis, however, is pretty
pointless.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Georg Brandl]

Michael Hobbs wrote:

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
readabilit y, 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?

For me, the above are not special cases in the sense that "leaving off the
line continuation character is allowed only in the line beginning a new suite"
is.

A similar special case would be, e.g., if triple quoted strings were
automatically dedented, but only if there's no text between the opening
quotes and the first linebreak. Etc. etc.

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

Of course. This is why the Zen includes more than one statement.

Georg

[Ben Finney]

Michael Hobbs <mi**@hobbshous e.orgwrites:

To be clear, this is the actual thrust of my argument. It seems
redundant to have *both* line continuations and colons in compound
statements.

Why are you trying to remove redundancy? The language is designed for
communication between people (programmers) primarily. Redundancy is
often the best way to be explicit and readable.

--
\ "I was in the first submarine. Instead of a periscope, they had |
`\ a kaleidoscope. 'We're surrounded.'" -- Steven Wright |
_o__) |
Ben Finney

[Ron Adam]

Michael Hobbs wrote:

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

Well, maybe you should consider working on that instead. I think you will get
much less resistance.
Consider the following points:

* There are not (that I know of) any true multiple line block headers in python
but only long block headers with continued lines.

* It's probably more beneficial to simplify the more complex cases of multiple
continued lines, than it is to simplify the already simple cases of non
continued block headers.

* The block header can be identified in all cases by the initiating keyword and
the terminating colon. (colons in lambda and dicts need to be identified first)

* The block header can not always be clearly identified strictly based on
indenting as indenting in a block header spanning several lines is completely
optional and may vary quite a bit depending on the programmers preferences.

* Line continuations are *already* currently optional in other situations.

>>a = (1,

.... 1,
.... 3,
.... 4,
.... 5)

>>a

(1, 1, 3, 4, 5)

>>b = (6, \

.... 7, \
.... 8, \
.... 9)

>>b

(6, 7, 8, 9)
* Making line continuations optional requires no changes to the existing library.

* Removing colons would require changing block headers for all existing programs
and pythons library unless you made the ending colon optional. But that
probably would create more confusion and hurt readability more than it improves it.
So giving these points, and any others you can think of, which do you suppose
has a better chance of being implemented?

It also needs to be pointed out that the line continuations are a strong visual
indication that a line is continued and not just a aid to the compiler. So
there will be resistance to changing that also. (Over and above the general
resistance to change most people have.)

Cheers,
Ron

[Michael Hobbs]

Robert Kern wrote:

Michael Hobbs wrote:

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

Empirical usability research carries a lot of weight. Certainly more so than
projection of personal preferences.

Yes, but all we have is a passing mention of it in the FAQ. If someone
could actually find the full content of the study and show that it is
[still] relevant to Python, I'd give it a lot of weight too. As it
stands, I've become far too jaded by so-called "studies" (both technical
and medical) to accept them on blind faith.

But for what it's worth, my personal preference is that having the colon is more
readable. Yours isn't. That's fine. Debating on that basis, however, is pretty
pointless.

True enough. Although, I have to ask how many times you define a new
function only to have Python spit a syntax error out at you saying that
you forgot a colon. It happens to me all the time. (Usually after an
"else") If you'd never notice that the colon was missing if the compiler
didn't point it out, is it really that readable? For me, I tend to get
annoyed at language "features" that I'm constantly tripping over.

- Mike

[John Salerno]

Ben Finney wrote:

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.

Ok, true, but there seems (to me) to be a difference between
content-related characters, such as giving more descriptive names to
variables, and syntax-related characters, such as colons and braces. I
was thinking strictly of the language syntax and not necessarily about
making the code quite literally more readable (with real words for
variables instead of 'x', or 'timv' instead of 'this_is_my_var iable').

[Ron Adam]

Michael Hobbs wrote:

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.

And you may be entirely correct that it doesn't improve readability "that much"
or not enough to matter. So at some point some body made a choice and now that's
what we have.

But the situation of readability now is influenced by that choice made then. If
it was a close call when abc was designed, enough so that a study was needed to
decide, It has now become what we are used to. And familiarity probably has a
bigger effect on readability.

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

As I said above, it may in fact be the way it is, simply because someone at some
point made a choice for what ever reason they had at the time. But changing
this particular item at this time isn't something that would be practical. (my
opinion) So probably the best you can expect is for a few people to agree with
you. Which is fine.

If enough people were to agree with you, you could start a group effort to write
your own version of python and distribute that. There's nothing preventing
anyone from doing that.

Cheers,
Ron

[sjdevnull]

Michael Hobbs wrote:

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.

Really?

Just looking at our real-world Python code (roughly 325,000 lines of
code in about 5,000 files), I see:
3 classes define __getattr__
1 call to __getattr__, which is an upcall from within one of those 3
__getattr__ definitions
17 classes define __repr__
0 explicit __repr__ calls
0 calls or definitions of __nonzero__
0 calls to super

That's hardly "filled with" in my book.

Really, there are only 3 widely used __foo__ strings in most of the
real-world Python code I've seen; __init__, __name__=="__ma in__" tests,
and __class__.

Aside from those, I normally see __foo__ tags only where you'd really
expect to--custom importers, dictionaries with lazy value retrieval,
class definitions overriding default behavior, etc. Not newbie stuff
at all, and not particularly common.

Of the 5,000 files we have, only 80 have any __foo__ tag aside from the
3 widely used ones.

[Steve Holden]

John Salerno wrote:

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?

No. The braces are gone because they don't assist a reader's
determination of block structure like indentation does. Otherwise why
would people write indenting pretty printers for C and the like?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Steve Holden]

Michael Hobbs wrote:

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.

In fact most Python doesn't use such constructs, though I'll admit the
occasional __init__ is more or less inevitable once you start using the
object-oriented features more than casually.

You are talking about some fairly advanced introspection, and the double
under naming conventions were chosen precisely to indicate that some
fairly special voodoo was being invoked. Readability is relative, and by
the time you have the need to use the magic names they probably won't
interfere with your reading overmuch.

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

I might take your admittedly cheerful wibbling a little more seriously
if, rather than trying to argue that the ABC study isn't valid for
Python, you came up with some sort of result that supported your ideas
(which I accept you aren't really concerned to promote: does this make
you a troll?)

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden