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_end_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 "heavyweight".
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 professionalness 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 "lightweight"
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

[John Salerno]

Post by Dan Lenski
So, is there another toolkit I should be looking at?

I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well. I can't really compare it to
other toolkits (not having used any of them, except Tkinter), but it's
definitely one of the most popular and well-supported ones out there.

http://www.wxpython.org/

[John Henry]

Post by John Salerno

Post by Dan Lenski
So, is there another toolkit I should be looking at?

I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well. I can't really compare it to
other toolkits (not having used any of them, except Tkinter), but it's
definitely one of the most popular and well-supported ones out there.
http://www.wxpython.org/

I highly recommend that you try PythonCard (which sits on top of
wxPython). You can get productive very very quickly. Take a look at:

http://pythoncard.sourceforge.net/walkthrough1.html

[Bill Maxwell]

Post by John Henry

Post by John Salerno

Post by Dan Lenski
So, is there another toolkit I should be looking at?

I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well. I can't really compare it to
other toolkits (not having used any of them, except Tkinter), but it's
definitely one of the most popular and well-supported ones out there.
http://www.wxpython.org/

I highly recommend that you try PythonCard (which sits on top of
http://pythoncard.sourceforge.net/walkthrough1.html

I took a brief look at PythonCard almost a year ago and got discouraged
by what I found, so I stopped looking at it. I've inserted my notes
from back then, below. Does anybody know if these things have been
fixed in the latest release?

Bill


=====================================================================
My notes from Fri Dec-23-2005:

This is a list of gripes I have while trying to learn about PythonCard.
I'm trying to investigate various GUI builders for Python, and
PythonCard looks promising, but a lot of things are getting in the way.

I installed yesterday, using this installer:
PythonCard-0.8.1.FIXED.win32.exe

A) The very first example in the tutorial is wrong!

On this page: http://pythoncard.sourceforge.net/documentation.html
When you follow this link to try something for the very first time:

Getting Started in PythonCard by Dan Shafer:
http://pythoncard.sourceforge.net/walkthrough1.html

You quickly see that the minimal.py example doesn't even contain
this line, even though the tutorial refers to it:

def on_menuFileAbout_select(self, event):

And, of course, if you replace the word "pass" with this, as
instructed:

result = dialog.alertDialog(self, 'It works!', 'Showing Off')

it won't run, because the existing "pass" line isn't inside a def
inside of a class.


B) Is the Notebook widget really supported?

In the installed file "changelog.txt" (gets installed as part of
PythonCard installation), it says:

"added Notebook component, PageBackground, and testNotebook
sample"

But, the testNotebook sample is nowhere to be found.

I looked lots of places, including the main SourceForge web site,
and on the wiki, here:

http://wiki.wxpython.org/index.cgi/PythonCard

Both the main website and the wiki seem way out of date, and the
latest dates I could find on both of them are sometime in 2004.

Finally, by following the mailing list archive link on the main
website, I managed to find a reference to the notebook component on the
ASPN site, where some guy named Brian wonders about the same thing as
me, concerning the availability of the notebook component:

http://aspn.activestate.com/ASPN/Mail/Message/pythoncard/2536825

and, that message led me here:

http://article.gmane.org/gmane.comp.python.pythoncard/1060

where Kevin Altis admits that he forgot to include it in the 0.8.1
release! At least he provides a way to download it separately. But,
gheesh, this is pretty poor for a new user. I was interested in using
the notebook component right away, because I looked at the wxGlade
tutorial before looking at PythonPage, and they use the notebook
component in their example (and I decided I really want to use the
component).

To add insult to injury, after you download the zip file with the
testNotebook stuff, the readme file says this:

"Until we have a Notebook integrated into some of the other
samples or tools this will serve as a basic test app, but I don't expect
to include it in releases."

C) Are the websites being maintained?

[John Henry]

Post by Bill Maxwell

Post by John Henry

Post by John Salerno

Post by Dan Lenski
So, is there another toolkit I should be looking at?

I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well. I can't really compare it to
other toolkits (not having used any of them, except Tkinter), but it's
definitely one of the most popular and well-supported ones out there.
http://www.wxpython.org/

I highly recommend that you try PythonCard (which sits on top of
http://pythoncard.sourceforge.net/walkthrough1.html

I took a brief look at PythonCard almost a year ago and got discouraged
by what I found, so I stopped looking at it. I've inserted my notes
from back then, below. Does anybody know if these things have been
fixed in the latest release?
Bill
=====================================================================
This is a list of gripes I have while trying to learn about PythonCard.
I'm trying to investigate various GUI builders for Python, and
PythonCard looks promising, but a lot of things are getting in the way.
PythonCard-0.8.1.FIXED.win32.exe
A) The very first example in the tutorial is wrong!
On this page: http://pythoncard.sourceforge.net/documentation.html
http://pythoncard.sourceforge.net/walkthrough1.html
You quickly see that the minimal.py example doesn't even contain

I am not sure which one you are referring to but in the
PythonCard\samples\minimal, you will find a minimal.py that says:

#!/usr/bin/python

"""
__version__ = "$Revision: 1.8 $"
__date__ = "$Date: 2005/12/17 15:20:02 $"
"""

from PythonCard import model


class Minimal(model.Background):
def on_menuFileAbout_select(self, event):
pass

if __name__ == '__main__':
app = model.Application(Minimal)
app.MainLoop()

Post by Bill Maxwell
And, of course, if you replace the word "pass" with this, as
result = dialog.alertDialog(self, 'It works!', 'Showing Off')
it won't run, because the existing "pass" line isn't inside a def
inside of a class.

No, it didn't work because the author forgot to mention that you have
to do a:

from PythonCard import model, dialog

instead of just:

from PythonCard import model

I just tried it and it works.

Post by Bill Maxwell
B) Is the Notebook widget really supported?
In the installed file "changelog.txt" (gets installed as part of
"added Notebook component, PageBackground, and testNotebook
sample"
But, the testNotebook sample is nowhere to be found.

I haven't come across a need to use Notebook and so I can not say for
sure. Looking at notebook.py, it appears to be just a simple wrapper
on top of the wxWindow notebook. I would encourage you to post a
message to the mailing list and ask there.

Post by Bill Maxwell
I looked lots of places, including the main SourceForge web site,
http://wiki.wxpython.org/index.cgi/PythonCard
Both the main website and the wiki seem way out of date, and the
latest dates I could find on both of them are sometime in 2004.

Yes, sometime around 2004, the website updating stopped. Fortunately,
development didn't. There are quite a number of new things since then:
new resource editor (now call layout Editor, standalone exe creator,
and so forth). I even learn that a new sizer handler is in the work.

Not saying that there are 10 programmers working 7/24 on it. It *is*
an Open Source project nevertheless. Nobody gets paid for doing it.
But there are development work going on.

Post by Bill Maxwell
Finally, by following the mailing list archive link on the main
website, I managed to find a reference to the notebook component on the
ASPN site, where some guy named Brian wonders about the same thing as
http://aspn.activestate.com/ASPN/Mail/Message/pythoncard/2536825
http://article.gmane.org/gmane.comp.python.pythoncard/1060
where Kevin Altis admits that he forgot to include it in the 0.8.1
release! At least he provides a way to download it separately. But,
gheesh, this is pretty poor for a new user. I was interested in using
the notebook component right away, because I looked at the wxGlade
tutorial before looking at PythonPage, and they use the notebook
component in their example (and I decided I really want to use the
component).
To add insult to injury, after you download the zip file with the
"Until we have a Notebook integrated into some of the other
samples or tools this will serve as a basic test app, but I don't expect
to include it in releases."

As with all Open Source projects, your mileage differs. PythonCard
does what *I* need to get done - and allowed me to get it done in a
*hurry*. May be you really need Notebook and may be it's true that
Notebook really doesn't work, I don't know. But if you managed to get
it working, write it up and get it included. That's what Open Source
Projects are all about.

Post by Bill Maxwell
C) Are the websites being maintained?

It appears that the maintainer of the web site stopped updating it
since late 2004. I don't know why. May be he's been busy. May be he
got mad. I don't know. All I know is that I have been very
productive with what I need to get done (and earned a happy living with
the code I created) and I am very grateful to the people that worked on
it - past and present.

I am not a "professional programmer" and so I probably can't contribute
to the development effort itself. However, I've gotten pretty good in
using most of the package (other then Notebook, I admit). So, if you
have any specific questions, please post it to the PythonCard list and
I'll try to help if I can.

Cheers.

[John Henry]

Upon closer look, the walkthrough did say:

***************************
from PythonCard import model

Change that so it says:

from PythonCard import dialog, model

Save the code.
***************************

So, it works.

Post by John Henry

Post by Bill Maxwell

Post by John Henry

Post by John Salerno

Post by Dan Lenski
So, is there another toolkit I should be looking at?

I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well. I can't really compare it to
other toolkits (not having used any of them, except Tkinter), but it's
definitely one of the most popular and well-supported ones out there.
http://www.wxpython.org/

I highly recommend that you try PythonCard (which sits on top of
http://pythoncard.sourceforge.net/walkthrough1.html

I took a brief look at PythonCard almost a year ago and got discouraged
by what I found, so I stopped looking at it. I've inserted my notes
from back then, below. Does anybody know if these things have been
fixed in the latest release?
Bill
=====================================================================
This is a list of gripes I have while trying to learn about PythonCard.
I'm trying to investigate various GUI builders for Python, and
PythonCard looks promising, but a lot of things are getting in the way.
PythonCard-0.8.1.FIXED.win32.exe
A) The very first example in the tutorial is wrong!
On this page: http://pythoncard.sourceforge.net/documentation.html
http://pythoncard.sourceforge.net/walkthrough1.html
You quickly see that the minimal.py example doesn't even contain

I am not sure which one you are referring to but in the
#!/usr/bin/python
"""
__version__ = "$Revision: 1.8 $"
__date__ = "$Date: 2005/12/17 15:20:02 $"
"""
from PythonCard import model
pass
app = model.Application(Minimal)
app.MainLoop()

Post by Bill Maxwell
And, of course, if you replace the word "pass" with this, as
result = dialog.alertDialog(self, 'It works!', 'Showing Off')
it won't run, because the existing "pass" line isn't inside a def
inside of a class.

No, it didn't work because the author forgot to mention that you have
from PythonCard import model, dialog
from PythonCard import model
I just tried it and it works.

Post by Bill Maxwell
B) Is the Notebook widget really supported?
In the installed file "changelog.txt" (gets installed as part of
"added Notebook component, PageBackground, and testNotebook
sample"
But, the testNotebook sample is nowhere to be found.

I haven't come across a need to use Notebook and so I can not say for
sure. Looking at notebook.py, it appears to be just a simple wrapper
on top of the wxWindow notebook. I would encourage you to post a
message to the mailing list and ask there.

Post by Bill Maxwell
I looked lots of places, including the main SourceForge web site,
http://wiki.wxpython.org/index.cgi/PythonCard
Both the main website and the wiki seem way out of date, and the
latest dates I could find on both of them are sometime in 2004.

Yes, sometime around 2004, the website updating stopped. Fortunately,
new resource editor (now call layout Editor, standalone exe creator,
and so forth). I even learn that a new sizer handler is in the work.
Not saying that there are 10 programmers working 7/24 on it. It *is*
an Open Source project nevertheless. Nobody gets paid for doing it.
But there are development work going on.

Post by Bill Maxwell
Finally, by following the mailing list archive link on the main
website, I managed to find a reference to the notebook component on the
ASPN site, where some guy named Brian wonders about the same thing as
http://aspn.activestate.com/ASPN/Mail/Message/pythoncard/2536825
http://article.gmane.org/gmane.comp.python.pythoncard/1060
where Kevin Altis admits that he forgot to include it in the 0.8.1
release! At least he provides a way to download it separately. But,
gheesh, this is pretty poor for a new user. I was interested in using
the notebook component right away, because I looked at the wxGlade
tutorial before looking at PythonPage, and they use the notebook
component in their example (and I decided I really want to use the
component).
To add insult to injury, after you download the zip file with the
"Until we have a Notebook integrated into some of the other
samples or tools this will serve as a basic test app, but I don't expect
to include it in releases."

As with all Open Source projects, your mileage differs. PythonCard
does what *I* need to get done - and allowed me to get it done in a
*hurry*. May be you really need Notebook and may be it's true that
Notebook really doesn't work, I don't know. But if you managed to get
it working, write it up and get it included. That's what Open Source
Projects are all about.

Post by Bill Maxwell
C) Are the websites being maintained?

It appears that the maintainer of the web site stopped updating it
since late 2004. I don't know why. May be he's been busy. May be he
got mad. I don't know. All I know is that I have been very
productive with what I need to get done (and earned a happy living with
the code I created) and I am very grateful to the people that worked on
it - past and present.
I am not a "professional programmer" and so I probably can't contribute
to the development effort itself. However, I've gotten pretty good in
using most of the package (other then Notebook, I admit). So, if you
have any specific questions, please post it to the PythonCard list and
I'll try to help if I can.
Cheers.

[Bill Maxwell]

Post by John Henry
***************************
from PythonCard import model
from PythonCard import dialog, model
Save the code.
***************************
So, it works.

Thanks for looking into it. It sounds like either it has been fixed in
the newer version -- or I didn't do something correctly. It's been a
long time, and I was just going by the notes I made back then.

Post by John Henry

Post by John Henry

Post by Bill Maxwell

Post by John Henry

Post by John Salerno

Post by Dan Lenski
So, is there another toolkit I should be looking at?

I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well. I can't really compare it to
other toolkits (not having used any of them, except Tkinter), but it's
definitely one of the most popular and well-supported ones out there.
http://www.wxpython.org/

I highly recommend that you try PythonCard (which sits on top of
http://pythoncard.sourceforge.net/walkthrough1.html

I took a brief look at PythonCard almost a year ago and got discouraged
by what I found, so I stopped looking at it. I've inserted my notes
from back then, below. Does anybody know if these things have been
fixed in the latest release?
Bill
=====================================================================
This is a list of gripes I have while trying to learn about PythonCard.
I'm trying to investigate various GUI builders for Python, and
PythonCard looks promising, but a lot of things are getting in the way.
PythonCard-0.8.1.FIXED.win32.exe
A) The very first example in the tutorial is wrong!
On this page: http://pythoncard.sourceforge.net/documentation.html
http://pythoncard.sourceforge.net/walkthrough1.html
You quickly see that the minimal.py example doesn't even contain

I am not sure which one you are referring to but in the
#!/usr/bin/python
"""
__version__ = "$Revision: 1.8 $"
__date__ = "$Date: 2005/12/17 15:20:02 $"
"""
from PythonCard import model
pass
app = model.Application(Minimal)
app.MainLoop()

Post by Bill Maxwell
And, of course, if you replace the word "pass" with this, as
result = dialog.alertDialog(self, 'It works!', 'Showing Off')
it won't run, because the existing "pass" line isn't inside a def
inside of a class.

No, it didn't work because the author forgot to mention that you have
from PythonCard import model, dialog
from PythonCard import model
I just tried it and it works.

Post by Bill Maxwell
B) Is the Notebook widget really supported?
In the installed file "changelog.txt" (gets installed as part of
"added Notebook component, PageBackground, and testNotebook
sample"
But, the testNotebook sample is nowhere to be found.

I haven't come across a need to use Notebook and so I can not say for
sure. Looking at notebook.py, it appears to be just a simple wrapper
on top of the wxWindow notebook. I would encourage you to post a
message to the mailing list and ask there.

Post by Bill Maxwell
I looked lots of places, including the main SourceForge web site,
http://wiki.wxpython.org/index.cgi/PythonCard
Both the main website and the wiki seem way out of date, and the
latest dates I could find on both of them are sometime in 2004.

Yes, sometime around 2004, the website updating stopped. Fortunately,
new resource editor (now call layout Editor, standalone exe creator,
and so forth). I even learn that a new sizer handler is in the work.
Not saying that there are 10 programmers working 7/24 on it. It *is*
an Open Source project nevertheless. Nobody gets paid for doing it.
But there are development work going on.

Post by Bill Maxwell
Finally, by following the mailing list archive link on the main
website, I managed to find a reference to the notebook component on the
ASPN site, where some guy named Brian wonders about the same thing as
http://aspn.activestate.com/ASPN/Mail/Message/pythoncard/2536825
http://article.gmane.org/gmane.comp.python.pythoncard/1060
where Kevin Altis admits that he forgot to include it in the 0.8.1
release! At least he provides a way to download it separately. But,
gheesh, this is pretty poor for a new user. I was interested in using
the notebook component right away, because I looked at the wxGlade
tutorial before looking at PythonPage, and they use the notebook
component in their example (and I decided I really want to use the
component).
To add insult to injury, after you download the zip file with the
"Until we have a Notebook integrated into some of the other
samples or tools this will serve as a basic test app, but I don't expect
to include it in releases."

As with all Open Source projects, your mileage differs. PythonCard
does what *I* need to get done - and allowed me to get it done in a
*hurry*. May be you really need Notebook and may be it's true that
Notebook really doesn't work, I don't know. But if you managed to get
it working, write it up and get it included. That's what Open Source
Projects are all about.

Post by Bill Maxwell
C) Are the websites being maintained?

It appears that the maintainer of the web site stopped updating it
since late 2004. I don't know why. May be he's been busy. May be he
got mad. I don't know. All I know is that I have been very
productive with what I need to get done (and earned a happy living with
the code I created) and I am very grateful to the people that worked on
it - past and present.
I am not a "professional programmer" and so I probably can't contribute
to the development effort itself. However, I've gotten pretty good in
using most of the package (other then Notebook, I admit). So, if you
have any specific questions, please post it to the PythonCard list and
I'll try to help if I can.
Cheers.

[John Henry]

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

http://prdownloads.sourceforge.net/pythoncard/testNotebook.zip?download

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

canvas.setFillColor('gray')

to:

try:
canvas.setFillColor('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.

Post by Bill Maxwell

Post by John Henry
***************************
from PythonCard import model
from PythonCard import dialog, model
Save the code.
***************************
So, it works.

Thanks for looking into it. It sounds like either it has been fixed in
the newer version -- or I didn't do something correctly. It's been a
long time, and I was just going by the notes I made back then.

Post by John Henry

Post by John Henry

Post by Bill Maxwell

Post by John Henry

Post by John Salerno

Post by Dan Lenski
So, is there another toolkit I should be looking at?

I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well. I can't really compare it to
other toolkits (not having used any of them, except Tkinter), but it's
definitely one of the most popular and well-supported ones out there.
http://www.wxpython.org/

I highly recommend that you try PythonCard (which sits on top of
http://pythoncard.sourceforge.net/walkthrough1.html

I took a brief look at PythonCard almost a year ago and got discouraged
by what I found, so I stopped looking at it. I've inserted my notes
from back then, below. Does anybody know if these things have been
fixed in the latest release?
Bill
=====================================================================
This is a list of gripes I have while trying to learn about PythonCard.
I'm trying to investigate various GUI builders for Python, and
PythonCard looks promising, but a lot of things are getting in the way.
PythonCard-0.8.1.FIXED.win32.exe
A) The very first example in the tutorial is wrong!
On this page: http://pythoncard.sourceforge.net/documentation.html
http://pythoncard.sourceforge.net/walkthrough1.html
You quickly see that the minimal.py example doesn't even contain

I am not sure which one you are referring to but in the
#!/usr/bin/python
"""
__version__ = "$Revision: 1.8 $"
__date__ = "$Date: 2005/12/17 15:20:02 $"
"""
from PythonCard import model
pass
app = model.Application(Minimal)
app.MainLoop()

Post by Bill Maxwell
And, of course, if you replace the word "pass" with this, as
result = dialog.alertDialog(self, 'It works!', 'Showing Off')
it won't run, because the existing "pass" line isn't inside a def
inside of a class.

No, it didn't work because the author forgot to mention that you have
from PythonCard import model, dialog
from PythonCard import model
I just tried it and it works.

Post by Bill Maxwell
B) Is the Notebook widget really supported?
In the installed file "changelog.txt" (gets installed as part of
"added Notebook component, PageBackground, and testNotebook
sample"
But, the testNotebook sample is nowhere to be found.

I haven't come across a need to use Notebook and so I can not say for
sure. Looking at notebook.py, it appears to be just a simple wrapper
on top of the wxWindow notebook. I would encourage you to post a
message to the mailing list and ask there.

Post by Bill Maxwell
I looked lots of places, including the main SourceForge web site,
http://wiki.wxpython.org/index.cgi/PythonCard
Both the main website and the wiki seem way out of date, and the
latest dates I could find on both of them are sometime in 2004.

Yes, sometime around 2004, the website updating stopped. Fortunately,
new resource editor (now call layout Editor, standalone exe creator,
and so forth). I even learn that a new sizer handler is in the work.
Not saying that there are 10 programmers working 7/24 on it. It *is*
an Open Source project nevertheless. Nobody gets paid for doing it.
But there are development work going on.

Post by Bill Maxwell
Finally, by following the mailing list archive link on the main
website, I managed to find a reference to the notebook component on the
ASPN site, where some guy named Brian wonders about the same thing as
http://aspn.activestate.com/ASPN/Mail/Message/pythoncard/2536825
http://article.gmane.org/gmane.comp.python.pythoncard/1060
where Kevin Altis admits that he forgot to include it in the 0.8.1
release! At least he provides a way to download it separately. But,
gheesh, this is pretty poor for a new user. I was interested in using
the notebook component right away, because I looked at the wxGlade
tutorial before looking at PythonPage, and they use the notebook
component in their example (and I decided I really want to use the
component).
To add insult to injury, after you download the zip file with the
"Until we have a Notebook integrated into some of the other
samples or tools this will serve as a basic test app, but I don't expect
to include it in releases."

As with all Open Source projects, your mileage differs. PythonCard
does what *I* need to get done - and allowed me to get it done in a
*hurry*. May be you really need Notebook and may be it's true that
Notebook really doesn't work, I don't know. But if you managed to get
it working, write it up and get it included. That's what Open Source
Projects are all about.

Post by Bill Maxwell
C) Are the websites being maintained?

It appears that the maintainer of the web site stopped updating it
since late 2004. I don't know why. May be he's been busy. May be he
got mad. I don't know. All I know is that I have been very
productive with what I need to get done (and earned a happy living with
the code I created) and I am very grateful to the people that worked on
it - past and present.
I am not a "professional programmer" and so I probably can't contribute
to the development effort itself. However, I've gotten pretty good in
using most of the package (other then Notebook, I admit). So, if you
have any specific questions, please post it to the PythonCard list and
I'll try to help if I can.
Cheers.

[Nick Craig-Wood]

Post by John Salerno

Post by Dan Lenski
So, is there another toolkit I should be looking at?

I highly recommend wxPython.

I'd second that!

There is a book also

"WxPython in Action"

http://www.amazon.com/Wxpython-Action-Noel-Rappin/dp/1932394621

Which is certainly my preferred way of learning new stuff!

Post by John Salerno
It's very mature, full-featured, and portable, and fairly easy to
learn as well.

...with native look and feel on each platform unlike GTK / TK

It has got a huge set of widgets and an excellent demo program in
which you can try them all out and steal their code.

There are some bits of it in which the C++ heritage sticks out, but
over the years the toolkit designers have been tucking those under the
carpet. The MethodNaming is a bit odd too!

A minor annoyance is that there are a number of features which only
work on a subset of the platforms. These are well documented though.

IMHO the best of the toolkits, but it is a personal choice and yours
may differ!

There is also PyQT which we wrote off as we wanted to write commercial
applications too. As it happens we have a commercial QT licence, but
we decided we didn't want to have to incurr the additional expense of
renewing it.

[Christophe]

Post by Nick Craig-Wood
There is also PyQT which we wrote off as we wanted to write commercial
applications too. As it happens we have a commercial QT licence, but
we decided we didn't want to have to incurr the additional expense of
renewing it.

Note: Nothing in the GPL prevents you from writting commecial software ;)

[Nick Craig-Wood]

Post by Christophe

Post by Nick Craig-Wood
There is also PyQT which we wrote off as we wanted to write commercial
applications too. As it happens we have a commercial QT licence, but
we decided we didn't want to have to incurr the additional expense of
renewing it.

Note: Nothing in the GPL prevents you from writting commecial
software ;)

A completely valid point!

s/commercial applications/closed source applications/ would be more
accurate.

However, in this case, our customer didn't want the source code
released as it contained some of their confidential stuff.

[Michael Hobbs]

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

[Paul Boddie]

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

The FAQ answer. ;-)

http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-if-while-def-class-statements

Paul

[Michael Hobbs]

Post by Paul Boddie

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

The FAQ answer. ;-)
http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-if-while-def-class-statements
Paul

I knew there was a document somewhere that I missed. ;-) I even scanned
all the Py3K PEPs before posting. Anyway, the FAQ answer seems to be a
weak argument to me. But if the BDFL insists that it remains, why not
take the converse approach? That is, assume that the expression ends at
the colon, not at the newline. That would make this type of statement
possible:
if color == red or
color == blue or
color == green:
return 'primary'
Right now, such a statement would have to be spelled thus:
if color == red or \
color == blue or \
color == green:
return 'primary'
or
if (color == red or
color == blue or
color == green):
return 'primary'

[Daniel Dittmar]

Post by Michael Hobbs
But if the BDFL insists that it remains, why not
take the converse approach? That is, assume that the expression ends at
the colon, not at the newline. That would make this type of statement

I suggested something like this a while back. The answer then was that
error messages in case of a forgotten colon would be misleading, at the
wrong position, or both.

Today:

if a or b
print x

File "colontest.py", line 2
if a or b
^
SyntaxError: invalid syntax

Daniel

[John Salerno]

Post by Michael Hobbs
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.

[Neil Cerutti]

Post by John Salerno

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.

I think it is outstanding that the colon's justification is
asthetic rather than technical (though I too had expected to see
a technical excuse for it).

[Tim Chase]

Post by Neil Cerutti

Post by John Salerno

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.

I think it is outstanding that the colon's justification is
asthetic rather than technical (though I too had expected to see
a technical excuse for it).

Though by such justifications based on asthetics, the interpreter
should also enforce that class-names begin with capital letters,
that camel-case is eschewed in favor of underscore_separation.
And perhaps enforce a 79-column character limit on text. Perhaps
also put a cap on the number of punctuation characters on a given
line as well to prevent the code from looking too much like
Perl... ;*)

A few arbitrary warts per-dictum of BDFL are fine though...it
still looks much cleaner compared to PHP & Perl ;-)

Shaving-with-Occam's-disposable-razor'ly yers...

-tkc

[Dennis Lee Bieber]

On Thu, 09 Nov 2006 14:44:21 -0600, Tim Chase

Post by Tim Chase
A few arbitrary warts per-dictum of BDFL are fine though...it
still looks much cleaner compared to PHP & Perl ;-)

Or line continuation in REXX... Where you get such oddities as:

call xyz(a, b, c, ,
d, e, f)

That is NOT a NULL argument between c and d... The first comma is the
argument separator, the second comma is the to-be-continued marker

[Neil Cerutti]

Post by Dennis Lee Bieber
On Thu, 09 Nov 2006 14:44:21 -0600, Tim Chase

Post by Tim Chase
A few arbitrary warts per-dictum of BDFL are fine though...it
still looks much cleaner compared to PHP & Perl ;-)

call xyz(a, b, c, ,
d, e, f)
That is NOT a NULL argument between c and d... The first comma
is the argument separator, the second comma is the
to-be-continued marker

Eyiyi! That's yugly.

The colon's main purpose seems to be to allow one-liners:

Easy to parse: if a < b: a += 1
Hard to parse if a < b a += 1

[s***@pobox.com]

Neil> The colon's main purpose seems to be to allow one-liners:

Neil> Easy to parse: if a < b: a += 1
Neil> Hard to parse if a < b a += 1

No, as the note from Tim Peters referenced by Robert Kern pointed out
earlier in this thread, the ABC language designers found that
indentation-based block structure by itself wasn't enough to clue new users
in about the code structure. Adding the colon at the end of the
if/while/for clause helped.

Skip

[Neil Cerutti]

Post by s***@pobox.com
Neil> Easy to parse: if a < b: a += 1
Neil> Hard to parse if a < b a += 1
No, as the note from Tim Peters referenced by Robert Kern
pointed out earlier in this thread, the ABC language designers
found that indentation-based block structure by itself wasn't
enough to clue new users in about the code structure. Adding
the colon at the end of the if/while/for clause helped.

Thanks. I worded that lousily.

[s***@pobox.com]

Neil> The colon's main purpose seems to be to allow one-liners:

Neil> Easy to parse: if a < b: a += 1
Neil> Hard to parse if a < b a += 1

Skip> ... the ABC language designers found that indentation-based block
Skip> structure by itself wasn't enough to clue new users in about the
Skip> code structure. Adding the colon at the end of the if/while/for
Skip> clause helped.

One final note. Just because the colon isn't technically required in many
situations doesn't mean it's superfluous. If all language designers cared
about was ease of parsing we'd probably all be programming in assembler,
sendmail, brainfuck. Or, as the Zen of Python says: "Readability counts".

Skip

P.S. I felt I just had to tie this into the thread on profanity somehow.
But notice that I didn't mention nazis or Hitler. ;-)

S

[Robert Kern]

Post by s***@pobox.com
P.S. I felt I just had to tie this into the thread on profanity somehow.
But notice that I didn't mention nazis or Hitler. ;-)

You did it just now!

[Neil Cerutti]

Post by Robert Kern

Post by s***@pobox.com
P.S. I felt I just had to tie this into the thread on
profanity somehow. But notice that I didn't mention nazis or
Hitler. ;-)

You did it just now!

I hate Godwin's Law Nazis.

;-)

[s***@pobox.com]

Post by s***@pobox.com
P.S. I felt I just had to tie this into the thread on profanity somehow.
But notice that I didn't mention nazis or Hitler. ;-)

Robert> You did it just now!

Hence the smiley. ;-)

S

[Robert Kern]

Post by Tim Chase
A few arbitrary warts per-dictum of BDFL are fine though...it
still looks much cleaner compared to PHP & Perl ;-)

Well, it's neither arbitrary nor simply the preference of the BFDL. The ABC
project actually did empirical experiments with programmers to find that code
comprehension improved by adding the colon.

Here's a post from Uncle Timmy mentioning it:

http://groups.google.com/group/comp.lang.python/browse_frm/thread/525480d0caa61b7f/8d568e684d653003?lnk=st&q=group%3Acomp.lang.python+ABC+colon+experiment&rnum=2#8d568e684d653003

Unfortunately, my Google-fu has not located an actual paper. It might be in here
somewhere:

http://homepages.cwi.nl/~steven/abc/publications.html

[Fredrik Lundh]

Post by John Salerno

Post by Michael Hobbs
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>

[Bjoern Schliessmann]

That is, assume that the expression ends at the colon, not at the
if color == red or
color == blue or
return 'primary'
if color == red or \
color == blue or \
return 'primary'
or
if (color == red or
color == blue or
return 'primary'

What about

if color == red or blue or green:
return 'primary'

:)

Really, I think it'd be more mess to let the if statement's end only
depend on ":". I think there could arise situations that are messy
to debug. If I need multiple lines I prefer the parentheses.

Regards,


Björn

[Neil Cerutti]

On 2006-11-09, Bjoern Schliessmann

Post by Bjoern Schliessmann
What about
return 'primary'
:)

The Inform 6* programming language supports the serial 'or' (and
'and') and looks just like that. The disadvantage is that the
usual binary logical operators must exist and are spelled
differently. (It uses C's '||' and '&&'.)

if (color == red or blue or green && color.type == additive) {
return 'primary';
}

It also supports a switch statement syntax and semantics that
would fit nicely with Python.

switch (action) {
Eat:
print "Gulp! Delicious, but poisonous.";
deadflag = 1;
Taste:
print "You nibble at one of the corners. Yum!";
Attack:
print "What did that mushroom ever to to you?";
default:
print "You can't do that to a mushroom.";
}

There's no fall-through, and there's no syntax to enable it,
either.

In Python it would hypothetically be:

switch action:
Eat:
print "Gulp! Delicious, but poisonous."
deadflag = True
Taste:
print "You nibble at one of the corners. Yum!"
Attack:
print "What did the mushroom ever to to you?"
default:
print "You can't do that to a mushroom."

I've often wanted a "Pythonic" Inform to Inform translator, so I
can leave out all the unecessary (), {} and ;.

* Inform 6 is a language for implementing text adventures, not
to be confused with the unrelated language Inform 7.

[Bjoern Schliessmann]

Post by Neil Cerutti
On 2006-11-09, Bjoern Schliessmann

Post by Michael Hobbs
return 'primary'
:)

The Inform 6* programming language supports the serial 'or' (and
'and') and looks just like that.

Python also supports it.

Post by Neil Cerutti
The disadvantage is that the usual binary logical operators must
exist and are spelled differently. (It uses C's '||' and '&&'.)

Do they have to be spelled differently? In Python, they don't have
to.

Regards,


Björn

[Neil Cerutti]

Post by Bjoern Schliessmann

Post by Neil Cerutti
On 2006-11-09, Bjoern Schliessmann

Post by Michael Hobbs
return 'primary'
:)

The Inform 6* programming language supports the serial 'or' (and
'and') and looks just like that.

Python also supports it.

Post by Neil Cerutti
The disadvantage is that the usual binary logical operators
must exist and are spelled differently. (It uses C's '||' and
'&&'.)

Do they have to be spelled differently? In Python, they don't
have to.

That kind of answers your question. ;-)

That is cool. I was unaware of the feature; until just now I
thought Inform was had innovated the syntax!

[Marc 'BlackJack' Rintsch]

Post by Bjoern Schliessmann

Post by Neil Cerutti
On 2006-11-09, Bjoern Schliessmann

Post by Michael Hobbs
return 'primary'
:)

The Inform 6* programming language supports the serial 'or' (and
'and') and looks just like that.

Python also supports it.

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.

Ciao,
Marc 'BlackJack' Rintsch

[Bjoern Schliessmann]

Post by Marc 'BlackJack' Rintsch
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

[James Cunningham]

On 2006-11-10 15:24:50 -0500, Bjoern Schliessmann

Post by Bjoern Schliessmann

Post by Marc 'BlackJack' Rintsch
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.

[Max Erickson]

color='orange'

print "Works?"


Works?

[James Cunningham]

Post by Max Erickson

color='orange'

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

[Steve Holden]

Post by James Cunningham
On 2006-11-10 15:24:50 -0500, Bjoern Schliessmann

Post by Bjoern Schliessmann

Post by Marc 'BlackJack' Rintsch
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"
...: print 'Works.'
Works.
...: print 'Works.'
Works.
...: print 'Works.'
Works.

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

Post by James Cunningham

Post by Bjoern Schliessmann

Post by Marc 'BlackJack' Rintsch
print 'yellow' == 'blue' or 'red' or 'green'

red

Post by James Cunningham

Post by Bjoern Schliessmann

Post by Marc 'BlackJack' Rintsch
print 'blue' == 'blue' or 'red' or 'green'

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

regards
Steve

[Fredrik Lundh]

Post by Bjoern Schliessmann

Post by Marc 'BlackJack' Rintsch
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?

Post by Marc 'BlackJack' Rintsch

color = "blue"

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

</F>

[Bjoern Schliessmann]

Post by Fredrik Lundh

color = "blue"

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

Whoops. Okay.

Regards,


Björn

[Steven D'Aprano]

Post by Bjoern Schliessmann

Post by Marc 'BlackJack' Rintsch
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)

[Bjoern Schliessmann]

Post by Steven D'Aprano
And just for the avoidance of doubt, Python "x == blue or red or
(x == blue) or bool(red) or bool(yellow)

Yep, got it. Shame on me, it's so obvious now :)

Regards,


Björn

[Ron Adam]

Post by Steven D'Aprano

Post by Bjoern Schliessmann

Post by Marc 'BlackJack' Rintsch
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

Maybe it should have been expressed as:

x == (blue or red or yellow)


Cheers,
Ron

[Steven D'Aprano]

Post by Ron Adam

Post by Steven D'Aprano

Post by Bjoern Schliessmann

Post by Marc 'BlackJack' Rintsch
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

x == (blue or red or yellow)

But that has very different semantics still -- since parentheses have the
highest priority, it means "evaluate (blue or red or yellow), then test if
x is equal to the result".

It might be useful on occasion to have a construct for "x equals blue or
red or yellow" in the sense used by normal English or Inform 6. And,
funnily enough, Python has such a construct. You just have to write "in"
instead of ==, and use a tuple for the terms:

x in (blue, red, yellow)

Not hard to remember, and unambiguous.

[Ron Adam]

Post by Steven D'Aprano

Post by Ron Adam

Post by Steven D'Aprano

Post by Bjoern Schliessmann

Post by Marc 'BlackJack' Rintsch
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

x == (blue or red or yellow)

But that has very different semantics still -- since parentheses have the
highest priority, it means "evaluate (blue or red or yellow), then test if
x is equal to the result".
It might be useful on occasion to have a construct for "x equals blue or
red or yellow" in the sense used by normal English or Inform 6. And,
funnily enough, Python has such a construct. You just have to write "in"
x in (blue, red, yellow)
Not hard to remember, and unambiguous.

Yes, that is the correct best way to do it, of course.

Funny thing is I tested a variation of the above version in a console and it
seemed to work, which surprised me. Now I can't get it to work, <scratching
head>. I don't know exactly what I typed in last night, so I can't figure out
what subtle (or overlooked obvious) characteristics my test had which gave me
the misleading results.

Sigh. I did think it was kind of odd it (apparently) worked, which was why I
phrased it as a suggestion.

Cheers,
Ron

[Hendrik van Rooyen]

"Fredrik Lundh" <***@pythonware.com> wrote:

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

Post by Fredrik Lundh

color = "blue"

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

ok the first condition is not true
the second "condition" 's string is not empty,
so take the true path...

BUT - the other way leads naturally to abominations like:

if color not equal to 'red' or 'green' or 'yellow'....

where 'green' and 'yellow' takes the "wrong" path,
as neither is equal to red, when what you wanted was:

if color not equal to 'red' and 'green' and 'yellow'...

Long live de Morgan!

In this Python simply requires you to be specific in what you want,
which is in a sense a GoodThing, seen as a BadThing by lazy programmers.

And as for the colon : colon schmolon - its irrelevant either way,
but if the interpreter requires it, you have no choice but to type it...

Programming is basically about guessing what was in the mind of the compiler
writer.

- Hendrik

[Fredrik Lundh]

Post by Hendrik van Rooyen

Post by Fredrik Lundh
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.

</F>

[Tony Nelson]

Post by Bjoern Schliessmann

That is, assume that the expression ends at the colon, not at the
if color == red or
color == blue or
return 'primary'
if color == red or \
color == blue or \
return 'primary'
or
if (color == red or
color == blue or
return 'primary'

What about
return 'primary'

What about

if color in [red, blue, green]:
return 'primary'
________________________________________________________________________
TonyN.:' *firstname****@georgea*lastname*.com
' <http://www.georgeanelson.com/>

[Steve Holden]

Post by Bjoern Schliessmann

That is, assume that the expression ends at the colon, not at the
if color == red or
color == blue or
return 'primary'
if color == red or \
color == blue or \
return 'primary'
or
if (color == red or
color == blue or
return 'primary'

What about
return 'primary'
:)
Really, I think it'd be more mess to let the if statement's end only
depend on ":". I think there could arise situations that are messy
to debug. If I need multiple lines I prefer the parentheses.

I still prefer

if color in (red, blue, green):
...

regards
Steve

[Steve Holden]

Post by Paul Boddie

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

The FAQ answer. ;-)
http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-if-while-def-class-statements
Paul

I suppose it would be even better if that hyperlink actually took you to
section 1.4.27 rather than 1.4.14 ...

regards
Steve

[Paul Boddie]

Post by Steve Holden

Post by Paul Boddie
http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-if-while-def-class-statements

I suppose it would be even better if that hyperlink actually took you to
section 1.4.27 rather than 1.4.14 ...

I'd suggest a browser upgrade: even the old version of Konqueror I'm
using here manages to scroll to the right place. And it isn't a Web
site maintenance problem, either, although I did have my suspicions.

Paul

[Steve Holden]

Post by Paul Boddie

Post by Steve Holden

Post by Paul Boddie
http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-if-while-def-class-statements

I suppose it would be even better if that hyperlink actually took you to
section 1.4.27 rather than 1.4.14 ...

I'd suggest a browser upgrade: even the old version of Konqueror I'm
using here manages to scroll to the right place. And it isn't a Web
site maintenance problem, either, although I did have my suspicions.

YTes, IE copes with it but Firefox doesn't. Having heard a number of
complaints about Firefox 2 I'm tempted to stick with 1.5.0.8 just a
little longer.

regards
Steve

[s***@yahoo.com]

Post by Steve Holden

Post by Paul Boddie

Post by Steve Holden

Post by Paul Boddie
http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-if-while-def-class-statements

I suppose it would be even better if that hyperlink actually took you to
section 1.4.27 rather than 1.4.14 ...

I'd suggest a browser upgrade: even the old version of Konqueror I'm
using here manages to scroll to the right place. And it isn't a Web
site maintenance problem, either, although I did have my suspicions.

YTes, IE copes with it but Firefox doesn't. Having heard a number of
complaints about Firefox 2 I'm tempted to stick with 1.5.0.8 just a
little longer.

FWIW, Firefox 2.0 and 1.5.0.7 both work properly on this link (as does
Epiphany 1.2.10). Linux 2.6-based system.

[Marc 'BlackJack' Rintsch]

Post by Michael Hobbs
Python is already sensitive to whitespace and the newline anyway, so why
not put it to good use? For example, Python rejects this statement
if self.hungry or
self.eat()
if self.hungry or \
self.eat()

You don't need the backslash if you use parenthesis:

if (self.hungry
or self.depressed):
self.eat()

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

I would miss auto-indenting in my editor to which the colon at the line
end is an important clue.

Ciao,
Marc 'BlackJack' Rintsch

[Ben Finney]

Please don't hide your new thread as a reply to an existing, unrelated
message. Start a new message if your message isn't actually a reply.

Post by Michael Hobbs
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
self.eat()
to
if self.hungry
self.eat()

But it can't be dropped from this statement:

if self.hungry: self.eat()

Post by Michael Hobbs
The colon that divides the statement therefore seems redundant. The
if self.hungry: self.eat()

Why have two different syntaxes for the same statement?

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

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

[Dan Lenski]

Post by Ben Finney

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

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

I agree completely. And as a recent convert to Python, I have to say
that I *like* the colons. I found the whitespace-and-colon thing
really irritating... for about 2 hours.

The colon makes it easier to eyeball where a block statement begins in
the absence of braces around the block, it allows one-line if
statements (which I use a lot), and it means that even the stupidest,
simplest editor can figure out where auto-indentation is needed, namely
following any line that ends with a colon (except in a triple-quoted, I
guess).

Contrast that with Perl, where in years of professional and hobby use I
have not found a single editor that gets indentation right more than
about 90% of the time. The syntax is too darn complicated. With
Python, figuring out where to auto-indent is trivial. Works for me.

Dan

[Michael Hobbs]

Post by Ben Finney
Please don't hide your new thread as a reply to an existing, unrelated
message. Start a new message if your message isn't actually a reply.

My apologies. My email client was apparently hiding some important
headers from me.

Post by Ben Finney

Post by Michael Hobbs
The colon that divides the statement therefore seems redundant. The
if self.hungry: self.eat()

Why have two different syntaxes for the same statement?

Why am I allowed separate statements with semi-colons in addition to
newlines? Why have triple-quoted long strings in addition to
single-quoted short strings? Why do I have to type backslash to continue
a line, except when I'm currently inside parens, brackets, or braces?

The answer is that it's a matter of convenience for the most common
case, with some exceptions allowed for the exceptional cases.

Post by Ben Finney

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

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.

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

- Mike

[Steven D'Aprano]

Post by Michael Hobbs
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.
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.

[s***@pobox.com]

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

Where can I read about mushrooms as animals?

Skip

[Steven D'Aprano]

Post by s***@pobox.com
Steven> The world seems to be flat, the sun appears to rotate around the
Steven> Earth, and mushrooms look like they are more closely related to
Steven> plants than to animals, but none of these things are actually
Steven> the case.
Where can I read about mushrooms as animals?

Mushrooms, like all fungi, aren't animals. The old divide of the
living world into animals and plants has been obsolete in biology for
decades. Biologists today generally follow Woese's "Six Kingdoms":

Eubacteria ("ordinary bacteria")
Archaebacteria ("extrophile bacteria")
Fungi
Plantae (plants)
Animalia (animals)
Protista (eukaryotes that are neither fungi, plants or animals -- a
grab-bag of "things left over" such as protozoa and algae)

Notice that, although to the naked microscope eubacteria and
archaebacteria seem very similar, their biochemistry is radically
different -- more so than (say) an oak tree and you or I.

Based on molecular and DNA evidence, fungi and animals are more similar
than fungi and plants. (Remember that animals include many thousands of
species that don't walk or crawl or fly, beasties like corals, sponges and
other creatures that look superficially plant-like.) Both animals and
fungi rely on plants to convert solar energy into chemical forms that they
can digest.

The best evidence is that the animal kingdom (including, naturally, human
beings) and fungi split during the Mesoproterozoic Era, approximately
1500-2000 million years ago. The common ancestor ("concestor") of animals
and fungi split from plants not long before that, where by "not long" I
of course mean "many hundreds of millions of years".

Richard Dawkins' excellent book "The Ancestor's Tale" is worth reading for
more about this. But keep in mind that biology is in a constant state of
flux these days, with new molecular discoveries virtually every day, so
dates are naturally uncertain and subject to revision. (Aside: this
willingness, even desire, to revise old beliefs in the light of new
evidence disproves the Creationist canard that evolution is a matter of
faith rather than science -- but I digress.)

See also http://en.wikipedia.org/wiki/Fungi for more about fungi including
mushrooms, although regrettably little on their evolutionary relationship
with other species. Follow the references there to discover more.

http://en.wikipedia.org/wiki/Kingdom_%28biology%29 discusses the
biological kingdoms -- again, treat Wikipedia as the start, not the end,
of your reading :)

[Steve Holden]

[...]

Post by Michael Hobbs

Post by Ben Finney
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?

Post by Michael Hobbs
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.

regards
Steve

[Ron Adam]

Post by Michael Hobbs
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. Possibly
because if multi-line conditional expressions are the norm, dropping a colon
could result in valid (but incorrect) code instead of an error?

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.

Cheers,
Ron

[Georg Brandl]

Post by Ron Adam

Post by Michael Hobbs
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

[Ron Adam]

Post by Georg Brandl

Post by Ron Adam

Post by Michael Hobbs
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

A bit of a circular answer.

Why the rule? -> So not to break the rule?


I would guess this probably is more applicable in this case.

Explicit is better than implicit.


Ron

[Georg Brandl]

Post by Ron Adam

Post by Georg Brandl

Post by Ron Adam

Post by Michael Hobbs
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

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.

Post by Ron Adam
I would guess this probably is more applicable in this case.
Explicit is better than implicit.

Of course, this always applies :)

Georg

[Ron Adam]

Post by Georg Brandl

Post by Ron Adam

Post by Georg Brandl

Post by Ron Adam

Post by Michael Hobbs
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

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.

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

If the requirement for line continuations was omitted for "any" block header
starting with a python keyword and ending with a colon, would it still be a
special case? It would be a bit less explicit. Are there situations where you
would want to explicitly limit a block header to just a single line because of
some negative consequence?

I'm asking more for just plain curiosity, and not suggesting this actually be
changed. In practice I don't think its enough of a issue to warrant changing in
python 2.x. Although it just may (coin toss here) be beneficial for python 3k
if extended annotations are implemented.

Ron

Post by Georg Brandl

Post by Ron Adam
I would guess this probably is more applicable in this case.
Explicit is better than implicit.

Of course, this always applies :)
Georg

[Michael Hobbs]

Post by Steve Holden
[...]

Post by Michael Hobbs

Post by Ben Finney
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".

Post by Steve Holden

Post by Michael Hobbs
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

[Steven D'Aprano]

Post by Michael Hobbs
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.

[Antoon Pardon]

Post by Steven D'Aprano

Post by Michael Hobbs
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.

[s***@pobox.com]

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

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_expression and
some_other_long_expression and
yet_another_long_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]

Post by Ron Adam
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

[Ron Adam]

Post by Michael Hobbs

Post by Ron Adam
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.

Post by Michael Hobbs
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

[Michael Hobbs]

Post by Ron Adam
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

[Steven D'Aprano]

Post by Michael Hobbs

Post by Ron Adam
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.

Post by Michael Hobbs
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.

Post by Michael Hobbs
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*

[Ron Adam]

Post by Michael Hobbs

Post by Ron Adam
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. ;)

[Paul Boddie]

Post by Ron Adam
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

[Ron Adam]

Post by Paul Boddie

Post by Ron Adam
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

Thanks for the link. I haven't heard about ita before. As one who constantly
struggles with spelling, I wouldn't be adverse to such a change. But of course
that would not be the best way to promote python.

Ron

[Fredrik Lundh]

Post by Michael Hobbs
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.

nice try, troll boy.

</F>

[John Salerno]

Post by Nick Craig-Wood

Post by John Salerno

Post by Dan Lenski
So, is there another toolkit I should be looking at?

I highly recommend wxPython.

I'd second that!
There is a book also
"WxPython in Action"

Oh yeah, how could I forget "The Book"! :) It's great to read straight
through, and also a fantastic reference, and covers just about all there
is to know to get very far in wxPython.

[Dan Lenski]

Post by Nick Craig-Wood

Post by John Salerno

Post by Dan Lenski
So, is there another toolkit I should be looking at?

I highly recommend wxPython.

I'd second that!
There is a book also
"WxPython in Action"

Nick and John S., thank you for the tip on wxPython! I'll look into it
for my next project. I too would avoid Qt, not because of the GPL but
simply because I don't use KDE under Linux and because Qt is not well
supported under Cygwin or on native Windows. I too like to learn from
actual printed books, so I'll check this one out. O'Reilly should do a
book on Python GUI stuff!

John H.: thanks for pointing out pythoncard. This looks like it might
be an excellent substitute for LabView-like GUIs, which all my
coworkers like. I personally refuse to read or write LabView code, on
the grounds that its syntax causes severe brain damage and is
completely unportable. But that's a flame for another thread, so to
speak...

Thanks,
Dan

[Christophe]

Post by Dan Lenski
Nick and John S., thank you for the tip on wxPython! I'll look into it
for my next project. I too would avoid Qt, not because of the GPL but
simply because I don't use KDE under Linux and because Qt is not well
supported under Cygwin or on native Windows.

Qt is very well supported under Windows! Avoid spreading lies please ;)


( and I must admit one of the reasons I avoid wx if possible, is because
I don't use Gnome under Linux and the look and feel of wx applications
is really horrible under KDE )

[Dan Lenski]

Post by Christophe

Post by Dan Lenski
Nick and John S., thank you for the tip on wxPython! I'll look into it
for my next project. I too would avoid Qt, not because of the GPL but
simply because I don't use KDE under Linux and because Qt is not well
supported under Cygwin or on native Windows.

Qt is very well supported under Windows! Avoid spreading lies please ;)

My apologies! I'm glad to be corrected on this. There are Cygwin
packages for Qt as well, but I have heard about enough bugs to think I
should avoid Qt. I have used enough Gtk apps that run flawlessly under
Windows to have my hopes that it works well.

Post by Christophe
( and I must admit one of the reasons I avoid wx if possible, is because
I don't use Gnome under Linux and the look and feel of wx applications
is really horrible under KDE )

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

[Jeremy Sanders]

Post by Dan Lenski
My apologies! I'm glad to be corrected on this. There are Cygwin
packages for Qt as well, but I have heard about enough bugs to think I
should avoid Qt. I have used enough Gtk apps that run flawlessly under
Windows to have my hopes that it works well.

You normally use PyQt/Qt on Windows without Cygwin. There are very few bugs
and lots of professional companies base their products on Qt Windows.

[James Cunningham]

[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.cgi/wxwin_wxplatforminfo.html

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

http://www.wxwidgets.org/wiki/index.php/WxWidgets_Compared_To_Other_Toolkits

Best,
James

[Nick Craig-Wood]

Post by Christophe
( and I must admit one of the reasons I avoid wx if possible, is because
I don't use Gnome under Linux and the look and feel of wx applications
is really horrible under KDE )

If you install the QT theme for GTK it all starts to look a lot nicer

Eg debian

ii gtk2-engines-gtk-qt 0.7-1 theme engine using Qt for GTK+ 2.x

You get a control panel for GTK apps in the KDE control center also.

[Jeremy Sanders]

Post by Dan Lenski
Nick and John S., thank you for the tip on wxPython! I'll look into it
for my next project. I too would avoid Qt, not because of the GPL but
simply because I don't use KDE under Linux and because Qt is not well
supported under Cygwin or on native Windows. I too like to learn from
actual printed books, so I'll check this one out. O'Reilly should do a
book on Python GUI stuff!

PyQt is well supported under native Windows. Qt-4 is now GPLd for Windows
too. I'd highly recommend it.

Jeremy

[John Henry]

Post by Dan Lenski
John H.: thanks for pointing out pythoncard. This looks like it might
be an excellent substitute for LabView-like GUIs, which all my
coworkers like. I personally refuse to read or write LabView code, on
the grounds that its syntax causes severe brain damage and is
completely unportable. But that's a flame for another thread, so to
speak...
Thanks,
Dan

I assume you meant that the example programs looks LabView-like GUIs?
PythonCard itself has nothing in common with LabView. It's more like
HyperCard.

[Dan Lenski]

Post by John Henry
I assume you meant that the example programs looks LabView-like GUIs?
PythonCard itself has nothing in common with LabView. It's more like
HyperCard.

That's right, I'm saying the GUIs *produced* by PythonCard look like
those produced by LabView. Believe me, if the PythonCard programming
style had anything to do with LabView, I'd avoid it like the plague =)

In any case, I think I'm gonna give PythonCard a shot before trying
full-fledged wxPython. It looks ideal for my needs.

Dan

[Steve Holden]

Post by Dan Lenski

Post by John Henry
I assume you meant that the example programs looks LabView-like GUIs?
PythonCard itself has nothing in common with LabView. It's more like
HyperCard.

That's right, I'm saying the GUIs *produced* by PythonCard look like
those produced by LabView. Believe me, if the PythonCard programming
style had anything to do with LabView, I'd avoid it like the plague =)
In any case, I think I'm gonna give PythonCard a shot before trying
full-fledged wxPython. It looks ideal for my needs.

You may find that it starts out fine, but becomes less satisfactory as
the sophistication of your interfaces increases. Then the problem will
be that migration to another platform demands a substantial rewrite of
your application (I have done this for a fairly small app).

I don't think PythonCard gets much maintenance nowadays.

regards
Steve

[John Henry]

Post by Steve Holden
You may find that it starts out fine, but becomes less satisfactory as
the sophistication of your interfaces increases. Then the problem will
be that migration to another platform demands a substantial rewrite of
your application (I have done this for a fairly small app).

It all depends on what you need. You can always "drop down" to calling
wxPython.

Post by Steve Holden
I don't think PythonCard gets much maintenance nowadays.

Funny you mention that. I started that discussion on the PythonCard
list only yesterday.

While it's true that the web pages hasn't been updated to follow up
with the developments, I am delighted to learn that there has been
quite a bit of work going on.

Again, it all depends on what your needs are. If you need to become
productive in a hurry, and you are not exactly chasing after the
latest widget, my recommendation is to go with PythonCard.

Post by Steve Holden
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

[Bjoern Schliessmann]

Post by Dan Lenski
for my next project. I too would avoid Qt, not because of the GPL
but simply because I don't use KDE under Linux and because Qt is
not well supported under Cygwin or on native Windows.

Why not?

BTW, big projects such as the Opera browser use Qt. Also in Windows.

Regards,


Björn

[Peter Decker]

Post by Dan Lenski
Nick and John S., thank you for the tip on wxPython! I'll look into it
for my next project. I too would avoid Qt, not because of the GPL but
simply because I don't use KDE under Linux and because Qt is not well
supported under Cygwin or on native Windows. I too like to learn from
actual printed books, so I'll check this one out. O'Reilly should do a
book on Python GUI stuff!
John H.: thanks for pointing out pythoncard. This looks like it might
be an excellent substitute for LabView-like GUIs, which all my
coworkers like. I personally refuse to read or write LabView code, on
the grounds that its syntax causes severe brain damage and is
completely unportable. But that's a flame for another thread, so to
speak...

You should also take a look at Dabo. Like PythonCard, it wraps
wxPython, but it completely does away with the whole getter/setter
approach, the ugly ALL_CAPS_CONSTANTS that wxPython unfortunately
inherited from its C++ roots, and all those other non-Pythonic
irritants. While Dabo is a complete 3-tier framework for developing
database apps, you can just use the GUI tier. I don't do database
stuff, and so I just use the dabo.ui module.

Their URL is http://dabodev.com.

[Wojciech Muła]

Post by Nick Craig-Wood

Post by John Salerno
It's very mature, full-featured, and portable, and fairly easy to
learn as well.

...with native look and feel on each platform unlike GTK / TK

AFAIK Tk 8 uses platform's native widgets.

w.

[Dan Lenski]

Post by Wojciech Muła

Post by Nick Craig-Wood

Post by John Salerno
It's very mature, full-featured, and portable, and fairly easy to
learn as well.

...with native look and feel on each platform unlike GTK / TK

AFAIK Tk 8 uses platform's native widgets.
w.

Tk 8.4 appears to use native Win32 widgets under Cygwin and native
WinXP. But it definitely doesn't use GTK widgets under Ubuntu with
Gnome desktop. Is there a way to get it to do so?

Dan

[Eric Brunel]

Post by Dan Lenski
Tk 8.4 appears to use native Win32 widgets under Cygwin and native
WinXP.

It seems to depend on the widget type, and on what you call native... Fo=
r =

example, tk menus are definitely the native ones; tk scrollbars are the =
=

native ones, but with the Win2k look (no XP look available yet); tk =

buttons do not seem to be the native ones, as they don't act like "norma=
l" =

Windows buttons.

Post by Dan Lenski
But it definitely doesn't use GTK widgets under Ubuntu with
Gnome desktop.

You seem to imply that GTK is "native" on Linux. It isn't, as can be see=
n =

with the echoes of the "holy war" between Gnome and KDE that we often se=
e =

around here. As an aside, I personnally work on Linux and don't even use=
=

any of these environments (both are too much Windows-like to my taste...=
).

Post by Dan Lenski
Is there a way to get it to do so?

Not yet. But tcl/tk 8.5 will include the Tile extension including new =

themable widgets. See here:
http://tktable.sourceforge.net/tile/screenshots/unix.html

There is also a Tile/QT extension that allows the Tile widgets to use th=
e =

QT library. See here:
http://www.ellogon.org/petasis/index.php?option=3Dcom_content&task=3Dvie=
w&id=3D24&Itemid=3D40

AFAIK, nothing equivalent for GTK yet.

HTH
-- =

python -c "print ''.join([chr(154 - ord(c)) for c in =

'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"

[Dan Lenski]

Post by Dan Lenski
Tk 8.4 appears to use native Win32 widgets under Cygwin and native
WinXP.

It seems to depend on the widget type, and on what you call native... For
example, tk menus are definitely the native ones; tk scrollbars are the
native ones, but with the Win2k look (no XP look available yet); tk
buttons do not seem to be the native ones, as they don't act like "normal"
Windows buttons.

So, basically, Tk is actually embedding the native Win2k menus, but it
isn't actually embedding the native Win2k scrollbars... it's just
emulating their look and feel?

Post by Dan Lenski
But it definitely doesn't use GTK widgets under Ubuntu with
Gnome desktop.

You seem to imply that GTK is "native" on Linux. It isn't, as can be seen
with the echoes of the "holy war" between Gnome and KDE that we often see
around here. As an aside, I personnally work on Linux and don't even use
any of these environments (both are too much Windows-like to my taste...).

I didn't imply that GTK widgets are "native" on Linux. I implied that
GTK widgets native under Gnome ;-) I was basing my assumption on an
earlier poster who said that Tk 8.x can use native widgets on all
supported platforms... so I assumed that under Gnome it should use GTK
widgets.

Post by Dan Lenski
Is there a way to get it to do so?

Not yet. But tcl/tk 8.5 will include the Tile extension including new
http://tktable.sourceforge.net/tile/screenshots/unix.html

Good to know! I'm looking forward to 8.5.

Dan

[Dan Lenski]

One other thing I'm wondering: how exactly does Tkinter work? Is the
whole Tk toolkit bound up as library of low-level C code, or does
Tkinter sit on top of a Tcl interpreter?

If the latter, that might explain why it is frustratingly slow on
Cygwin... since Cygwin is not very good at starting up new processes in
a timely manner.

Dan

[Eric Brunel]

Post by Dan Lenski
One other thing I'm wondering: how exactly does Tkinter work? Is the
whole Tk toolkit bound up as library of low-level C code, or does
Tkinter sit on top of a Tcl interpreter?

The latter: there is a tiny C layer allowing Python to call an embedded
tcl interpreter.

Post by Dan Lenski
If the latter, that might explain why it is frustratingly slow on
Cygwin... since Cygwin is not very good at starting up new processes in
a timely manner.

There is no other process involved: the interpreter is embedded, just as a
Python interpreter can be embedded in a C application. If you want to work
with Tkinter on Windows, you'd better avoid Cygwin. Python with Tkinter
works just fine on Windows, just as it works on any other platform, and is
fully portable, just as tcl/tk is.

HTH

[vdicarlo]

Post by John Salerno
I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well.

I am also a Python beginner thinking about what GUI toolkit to use, and
the availability of a free video screencast series on installing and
using wxpython at showmedo.com is making me want to go that way. I
viewed their introduction to Python resources and wished I had found it
first.

The wxpython series is at http://tinyurl.com/yggean

Vincent

[Florian Diesch]

Post by Dan Lenski
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?

For Gtk there's Kiwi <http://www.async.com.br/projects/kiwi/>



Florian