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

[skip]

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

[Dan Lenski]

Hendrik van Rooyen wrote:

"Fredrik Lundh" <fr*****@python ware.comwrote:

8<---------------------------------------------------

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

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

*grin* - this can be construed as a weakness in Python -

Even COBOL compilers in the sixties would "add in" the implied
"if color = " after each 'or', instead of bloody - mindedly thinking:

How the heck could this be considered a weakness in Python? I *like*
the fact that Python does not do anything "automagica l" and rewrite
expressions, thinking it's smarter than the programmer. That's one
reason I got sick of Perl.

There are plenty of cases where I might want to use an expression like
"color == red or foo or bar" with the semantics it actually implies in
Python. Making an exception for literal strings specifically seems
reallly dubious given the fact that Python already has an easy way to
do what you want with the "color in (red, green, blue)" construct.
This supposedly lacking feature would only be desired by people who
have been brain-damaged by programming languages like BASIC and
COBOL... or newbies who haven't programmed enough to really "get"
Boolean logic. </rant>

Dan

[Ron Adam]

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.

Ron

[Doug]

Michael Hobbs wrote:

Can anyone find a flaw with this change in syntax?

Instead of dividing a compound statement with a colon, why not divide it
on a newline? For example, the colon could be dropped from this statement:
if self.hungry:
self.eat()
to
if self.hungry
self.eat()

Python is already sensitive to whitespace and the newline anyway, so why
not put it to good use? For example, Python rejects this statement
because of the newline present:
if self.hungry or
self.depressed:
self.eat()
You need to use the backslash to continue the expression on the next line:
if self.hungry or \
self.depressed:
self.eat()
The colon that divides the statement therefore seems redundant. The
colon could continue to be used for single-line statements:
if self.hungry: self.eat()

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, B) the language was designed for children, and C) the
keywords in ABC are IN ALL CAPS LIKE THIS (hurting readability and
writeability) and thus adding a colon obviously helps restore some
readability for users in that case but not in python's.

However, python is far too old to accept any fundamental changes to
syntax at this point.

[Hendrik van Rooyen]

"Dan Lenski" <dl*****@gmail. comwrote:

Hendrik van Rooyen wrote:

"Fredrik Lundh" <fr*****@python ware.comwrote:

8<---------------------------------------------------

>>color = "blue"
>>if color == "red" or "green" or "yellow":
... print color, "is red or green or yellow"
...
blue is red or green or yellow

*grin* - this can be construed as a weakness in Python -

Even COBOL compilers in the sixties would "add in" the implied
"if color = " after each 'or', instead of bloody - mindedly thinking:

How the heck could this be considered a weakness in Python? I *like*
the fact that Python does not do anything "automagica l" and rewrite
expressions, thinking it's smarter than the programmer. That's one
reason I got sick of Perl.

There are plenty of cases where I might want to use an expression like
"color == red or foo or bar" with the semantics it actually implies in
Python. Making an exception for literal strings specifically seems
reallly dubious given the fact that Python already has an easy way to
do what you want with the "color in (red, green, blue)" construct.
This supposedly lacking feature would only be desired by people who
have been brain-damaged by programming languages like BASIC and
COBOL... or newbies who haven't programmed enough to really "get"
Boolean logic. </rant>

Dan

I am amazed by the reaction my grin and weakness comment has drawn -
it looks as if both you and the effbot did not bother to read and try to
understand the rest of that post, which gave an example of why the python
way is in fact good...

I apologise if my example is meaningless to people whose brains have not been
damaged by experience yet.

- Hendrik

[John Henry]

Nice example.
Jussi Salmela wrote:

John Henry wrote:

BTW: I did a search and found the testnotebook example from:

http://prdownloads.sourceforge.net/p...k.zip?download

and tried it out. There is one error in the widget.py that I have to
get around. Changed from:

canvas.setFillC olor('gray')

to:

try:
canvas.setFillC olor('gray')
except:
pass

and then ran it. Works!

So, yes, you can do Notebook in Python. I believe what they are saying
is that Notebook isn't supported fully (yet) in the resourceeditor.

It's true that the notebook and grid components of wxPython are not
completely integrated into PythonCard but they can still be used quite
easily once you figure out how.

The process of figuring out can be made easier by a working example. The
real life application Blood Pressure Monitor

http://personal.inet.fi/cool/operator/BPMDownload.html

can be used as an example of using the notebook, grid and htmlwin
widgets in PythonCard.

I use this application to input the pressure values I've registered with
my own meter and to produce a PDF page with PyChart to hand to my doctor
to inspect when I visit him twice a year.

Cheers,
Jussi

--
Jussi Salmela
http://personal.inet.fi/cool/operator/

[Carsten Haese]

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.

B) the language was designed for children,

http://www.cwi.nl/archive/projects/abc.html does not mention children:
"Originally intended as a language for beginners, it has evolved into a
powerful tool for beginners and experts alike."

and C) the
keywords in ABC are IN ALL CAPS LIKE THIS (hurting readability and
writeability) and thus adding a colon obviously helps restore some
readability for users in that case but not in python's.

So what are you saying? In a programming language that doesn't use all
caps keywords, adding colons to block-beginning lines hurts readability,
or it doesn't add any readability?

In any case, that's an assertion that should be backed up by citing
relevant research.

However, python is far too old to accept any fundamental changes to
syntax at this point.

The source code for Python is openly available. If you are so convinced
of the added readability from removing the colons, do the world a favor
and make the necessary change, or hire somebody to make the change, to
Python.

-Carsten

[Carsten Haese]

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.

B) the language was designed for children,

http://www.cwi.nl/archive/projects/abc.html does not mention children:
"Originally intended as a language for beginners, it has evolved into a
powerful tool for beginners and experts alike."

and C) the
keywords in ABC are IN ALL CAPS LIKE THIS (hurting readability and
writeability) and thus adding a colon obviously helps restore some
readability for users in that case but not in python's.

So what are you saying? In a programming language that doesn't use all
caps keywords, adding colons to block-beginning lines hurts readability,
or it doesn't add any readability?

In any case, that's an assertion that should be backed up by citing
relevant research.

However, python is far too old to accept any fundamental changes to
syntax at this point.

The source code for Python is openly available. If you are so convinced
of the added readability from removing the colons, do the world a favor
and make the necessary change, or hire somebody to make the change, to
Python.

-Carsten

[Carsten Haese]

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.

B) the language was designed for children,

http://www.cwi.nl/archive/projects/abc.html does not mention children:
"Originally intended as a language for beginners, it has evolved into a
powerful tool for beginners and experts alike."

and C) the
keywords in ABC are IN ALL CAPS LIKE THIS (hurting readability and
writeability) and thus adding a colon obviously helps restore some
readability for users in that case but not in python's.

So what are you saying? In a programming language that doesn't use all
caps keywords, adding colons to block-beginning lines hurts readability,
or it doesn't add any readability?

In any case, that's an assertion that should be backed up by citing
relevant research.

However, python is far too old to accept any fundamental changes to
syntax at this point.

The source code for Python is openly available. If you are so convinced
of the added readability from removing the colons, do the world a favor
and make the necessary change, or hire somebody to make the change, to
Python.

-Carsten

[Simon Brunning]

On 11/11/06, Fredrik Lundh <fr*****@python ware.comwrote:

Hendrik van Rooyen wrote:

blue is red or green or yellow

*grin* - this can be construed as a weakness in Python -

it's boolean logic, and it's incompatible with human use of the same
terms in all contexts, not just Python.

Indeed.

The other day, I way showing my eight year old, Freja, what a program
looks like:

your_name = raw_input("What 's your name? ")
if your_name.lower () == "freja":
print "You're very stinky,", your_name
else:
print "You smell lovely, ", your_name

After running it a couple of times, she dove in and changed the 2nd line to:

if your_name.lower () == "daddy or ella":

(Ella is my other daughter's name.) That's pretty close to correct,
I'd say - but you don't get anything for being close in a programming
language.

--
Cheers,
Simon B
si***@brunningo nline.net
http://www.brunningonline.net/simon/blog/