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

[Steve Holden]

James Cunningham wrote:

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.

Try testing a little more completely:

>>for color in ('blue', 'red', 'green', 'yellow'):

... if color == 'blue' or 'red' or 'green':
... print color, "compares true"
... else:
... print color, "compares false"
...
blue compares true
red compares true
green compares true
yellow compares true

>>>

Still think it works?

>>print 'yellow' == 'blue' or 'red' or 'green'

red

>>print 'blue' == 'blue' or 'red' or 'green'

True

>>>

Now do you understand why it doesn't work? Think "operator precedence".

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

[Michael Hobbs]

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.) This backup function
obviously isn't needed when a computer is taking care of the layout.

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

- Mike

[Bjoern Schliessmann]

Fredrik Lundh wrote:

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

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

Whoops. Okay.

Regards,
Björn

--
BOFH excuse #303:

fractal radiation jamming the backbone

[Ron Adam]

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.) This backup function
obviously isn't needed when a computer is taking care of the layout.

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

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

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.

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 think you will find that that is more complex than it sounds. Try writing
colorizing routines for both versions? Which is easier?

Cheers,
Ron
PS. Rather than shav of on character her and ther in pythons programing
languag, Lets remov all the silent leters from the english languag. That will
sav thousands mor kestroks over a few yers.

I think if you try that for a few months and then switch back, you will find
writing without the silent letters just feels more natural. ;)

[Steven D'Aprano]

On Fri, 10 Nov 2006 21:24:50 +0100, 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?

Inform 6 "x == blue or red or yellow" is equivalent to the Python

x == blue or x == red or x == yellow

or if you prefer:

x in (blue, red, yellow)

And just for the avoidance of doubt, Python "x == blue or red or yellow"
is semantically equivalent to:

(x == blue) or bool(red) or bool(yellow)

--
Steven.

[Steven D'Aprano]

On Fri, 10 Nov 2006 10:37:08 -0600, Michael Hobbs wrote:

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.

and then in a later post:

Like I said in that paragraph, removing the colon wouldn't seem to
degrade readability *that much*, if at all.

A little bit of skepticism is a wonderful thing, but in this particular
case, your "seems to provide" and "wouldn't seem to" are beaten quite
comprehensibly by the actual usability testing performed by the ABC
Project. (See Robert Kern's post earlier in this thread.)

The world seems to be flat, the sun appears to rotate around the Earth,
and mushrooms look like they are more closely related to plants than to
animals, but none of these things are actually the case.

When you've done your own usability testing, comparable to that already
done, then please feel free to let us know whether the evidence matches
your intuitions.
--
Steven.

[Steven D'Aprano]

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.

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.

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

[James Cunningham]

On 2006-11-09 14:06:06 -0500, "Dan Lenski" <dl*****@gmail. comsaid:

[snip]

My understanding is that wx wraps Windows, OSX, Qt, and GTK+... I guess
some of the wrappers fit the native apps better than others?

Dan

WxWidgets does wrap Windows, OS X (Carbon), and GTK; it does not wrap
Qt. On this page is a list of WxWidgets ports:

http://wiki.wxwidgets.org/docbrowse....tforminfo.html

According to the WxWidgets wiki, there's nothing stopping a person from
writing a Qt port.

http://www.wxwidgets.org/wiki/index....Other_Toolkits

Best,
James

[Paul Boddie]

Ron Adam wrote:

>
PS. Rather than shav of on character her and ther in pythons programing
languag, Lets remov all the silent leters from the english languag. That will
sav thousands mor kestroks over a few yers.

How about changing Python to support keywords and identifiers employing
the Initial Teaching Alphabet?

http://en.wikipedia.org/wiki/Initial_Teaching_Alphabet

;-)

Paul

[Steven D'Aprano]

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