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]

Steve Holden wrote:

Michael Hobbs wrote:

>Ben Finney wrote:

[...]

>>A use case. What problem is being solved by introducing this
inconsistency ?

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.

So you'd also like us to shorten the names of the builtins and the the
keywords? Why bother with "def" when we could just use "d", "class" when
we could just use "c"? Or *does* readability matter to some degree?

Like I said in that paragraph, removing the colon wouldn't seem to
degrade readability *that much*, if at all. Personally, even though I
find typing the colon to be a small annoyance, that annoyance exceeds
any improvement to readability that it might provide; especially
considering that indentation sticks out like a big red sign saying the
code block starts "HERE, HERE, HERE".

>As far as using the FAQ as gospel, the FAQ also provides arguments for
why there isn't a with statement or a switch statement. The with
statement has already been implemented in 2.5 and there's a PEP to
implement switch (3103).

But the "with" statement isn't the one that "with" was reserved for in
the FAQ, which is really talking about the same kind of "with" statement
that Visual Basic uses: an implied left operand for unary "." operations.

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.

- Mike

[skip]

Replying via Steve's not to (I think) a comment from Michael Hobbs
(apologies to Steve):

>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 use four-space indents whenever possible. If I have a multi-line
condition I find that the condition indents to the same level as the the
indented block, e.g.:

# Oh, wait, I shouldn't have typed that colon just now! It's not
# necessary. Oh, darn. Hmmm... What does Strunk say?
if (some_long_expr ession and
some_other_long _expression and
yet_another_lon g_expression):
that_was_a_long _expression = True

I don't know if this is just a shortcoming of the style I use to break lines
in a long expression or what, but the colon makes it clear where the
condition ends and the indented block begins.

Skip

[Michael Hobbs]

Ron Adam wrote:

The faq also pointed out a technical reason for requiring the colon. It makes
the underlying parser much easier to write and maintain. This shouldn't be
taken to lightly in my opinion, because a simpler easer to maintain and more
reliable python parser means development time can be spent improving the
language in other areas instead of fixing parsing problems every time a new
feature is added that might be used in a conditional expression.

Not to be too picky about it, but the FAQ was referring to editor
parsers, not the parser used by Python itself. The Python parser could
easily change its grammar to make the colon optional.

I find the editor parsing excuse to be weak since most editors tend to
get hung up on Python code anyway, regardless of the colons. (Except for
the ones that are specifically written to support Python, or are
insanely programmable, like emacs.) In fact, I find that my editor
usually gets confused when it comes across colons in dictionary literals
or lambda expressions. If it just stuck to looking at the indentation,
instead of trying to play off syntax tricks, it would behave much better.

- Mike

[Bjoern Schliessmann]

Marc 'BlackJack' Rintsch wrote:

No it doesn't -- look again at the example given above. It's
legal syntax in Python but doesn't have the semantics implied by
the example.

Sorry, I don't understand -- what is the difference between the
example as it is and the implied semantics of it?

Regards,
Björn

--
BOFH excuse #239:

CPU needs bearings repacked

[James Cunningham]

On 2006-11-10 15:24:50 -0500, Bjoern Schliessmann
<us************ **************@ spamgourmet.com said:

Marc 'BlackJack' Rintsch wrote:

>No it doesn't -- look again at the example given above. It's
legal syntax in Python but doesn't have the semantics implied by
the example.

Sorry, I don't understand -- what is the difference between the
example as it is and the implied semantics of it?

Regards,
Björn

Yes, I'm not sure myself.

In [1]: color = "red"

In [2]: if color == "red" or "blue" or "green":
...: print 'Works.'
...:
...:
Works.

In [3]: if color == "blue" or "red" or "green":
...: print 'Works.'
...:
...:
Works.

In [4]: if not color == "blue" or "green":
...: print 'Works.'
...:
...:
Works.

[Fredrik Lundh]

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>

[Fredrik Lundh]

Bjoern Schliessmann wrote:

Marc 'BlackJack' Rintsch wrote:

>No it doesn't -- look again at the example given above. It's
legal syntax in Python but doesn't have the semantics implied by
the example.

Sorry, I don't understand -- what is the difference between the
example as it is and the implied semantics of it?

>>color = "blue"
if color == "red" or "green" or "yellow":

.... print color, "is red or green or yellow"
....
blue is red or green or yellow

</F>

[Max Erickson]

>>color='orange '

>>if color=='red' or 'blue' or 'green':

print "Works?"
Works?

>>>

[James Cunningham]

On 2006-11-10 15:47:42 -0500, Max Erickson <ma*********@gm ail.comsaid:

>>>color='orang e'
if color=='red' or 'blue' or 'green':

print "Works?"
Works?

No! No no no. I won't hear of it.

Don't you know that with insufficient test cases, everything is right? Sheesh.

Best,
James

[Ron Adam]

Michael Hobbs wrote:

Ron Adam wrote:

>The faq also pointed out a technical reason for requiring the colon. It makes
the underlying parser much easier to write and maintain. This shouldn't be
taken to lightly in my opinion, because a simpler easer to maintain and more
reliable python parser means development time can be spent improving the
language in other areas instead of fixing parsing problems every time a new
feature is added that might be used in a conditional expression.

Not to be too picky about it, but the FAQ was referring to editor
parsers, not the parser used by Python itself. The Python parser could
easily change its grammar to make the colon optional.

Yes, hmm. I seem to remember (possibly falsely) of someone saying it did make
pythons parser simpler. Oh well. Making it easier for third party tools and
parser to parse is still worth while in my opinion.

I find the editor parsing excuse to be weak since most editors tend to
get hung up on Python code anyway, regardless of the colons. (Except for
the ones that are specifically written to support Python, or are
insanely programmable, like emacs.) In fact, I find that my editor
usually gets confused when it comes across colons in dictionary literals
or lambda expressions. If it just stuck to looking at the indentation,
instead of trying to play off syntax tricks, it would behave much better.

My editor (GVIM) has the most trouble with long triple quoted strings. I could
probably modify the script a bit and fix that though. I've never run into
problems with colons.

In another post on this thread you use an example of consistancy as a reason for
not having the colon. But maybe sometimes there can be too much consistency,
like when you want to differentiate something because they have different
contextual meaning.

xxx xxx:
yyy yyy
yyy yyy

Here the colon indicates a difference or change in context. A test vs a
procedure, or a grouping vs attributes, etc. I suppose you could also interpret
it as meaning 'related to'. In a way this is carried over to dictionaries where
a key is related to it's value. A range is related to the loop body, a test is
related to the if body, etc...

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.

Cheers,
Ron