How to choose the right GUI toolkit ?

[vdicarlo]

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

[Daniel Dittmar]

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

[Hendrik van Rooyen]

"Fredrik Lundh" <fredrik at pythonware.com> wrote:

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

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

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>

[Hendrik van Rooyen]

I think part of learning to think like a computer is learning to stop
associating computer logic too strongly with the natural language
meanings of "and", "or", and "not".

This is true - and you have left out "but"....

- Hendrik

[Hendrik van Rooyen]

Post by Fredrik Lundh

Post by Hendrik van Rooyen

blue is red or green or yellow

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

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

Indeed.
The other day, I way showing my eight year old, Freja, what a program
your_name = raw_input("What's your name? ")
print "You're very stinky,", your_name
print "You smell lovely, ", your_name
(Ella is my other daughter's name.) That's pretty close to correct,
I'd say - but you don't get anything for being close in a programming
language.

This is true - and it is actually also an intractable problem - if you look at
what your daughter wrote, you get the feeling that you should be able to write
an interpreter that can implement what she meant, because it is quite clear to
you - until you try to write the specs...

Your daughter, btw, will go far if she already has the guts to do that...

- Hendrik

[Simon Brunning]

Post by Fredrik Lundh

Post by Hendrik van Rooyen

blue is red or green or yellow

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

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

Indeed.

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

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

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

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

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

[Robert Kern]

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!

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

Robert> You did it just now!

Hence the smiley. ;-)

S

[Fredrik Lundh]

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>

[sjdevnull]

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.

[John Henry]

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.

[Steve Holden]

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

[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

[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

[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

[Michael Hobbs]

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

[Paul Boddie]

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

[Robert Kern]

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

Never.

I confess I find myself in the position of a Yorkshire Youngster - I don't
believe you!

Okay, not often enough or annoyingly enough for me to remember having done so.
Perhaps seven years ago when I started using Python, but not any time recent.

[Ron Adam]

Post by Michael Hobbs

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

[Michael Hobbs]

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

Trust me, my brain is quite filthy and doesn't wash easily. I do
appreciate aesthetics, which is why still stay with Python, even after
programming in Ruby for several months. I've used Java/C/C++ for years,
yet I make no complaint about the lack of static typing in Python. Even
so, I'd like to think that I know a good thing when I see it.

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

Not to repeat myself from an earlier post, but any pretense that
Python's primary objective is readability went out the window with the
invention of such constructs as "__del__", "__repr__", and
"super(MyClass, self).__init__()". There are obviously other goals to
the language's development that inspired these constructs and override
the priority of readability.

Post by Ron Adam
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 just may take you up on that. ;-) Not for a few days, though. Not
enough time right now.

- Mike

[Ron Adam]

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.

Ron> I wasn't that specific and it was related to Michael's suggestion
Ron> the colon wasn't needed. If the need for '\' was dropped in
Ron> multi-line block headers, then the colon would be required for an
Ron> obvious reason.
x = a + \
b
not just conditionals.
Skip

Of course, and your point is?

How about if it be ok to continue to use '\' in headers, but it also be ok to
not to? That would be the backward compatible way to change it.

This doesn't answer the question I was asking, are there any situation where it
would cause problems? And if so, that reason would be a good and explicit
reason for not making such a change.

Ron

[Steven D'Aprano]

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

Why are you trying to remove redundancy?

Why not? My impression is that removing redundancy is considered
a positive thing here in c.p.l.

Redundancy in *what*?

Redundancy is not something to be valued for its own sake. It is only
valuable when it actually gains you something.

e.g. x + y and x.__add__(y) are redundant, BUT __add__ is necessary for
operator overloading and + operator is necessary for readability and
easy arithmetic expressions.

Likewise, operator.add is useful for local optimizations, and so is to be
valued despite the redundancy of yet another way to do addition.

But a hypothetical built-in function add(x,y) => x+y would be redundant
for no good reason, and therefore to be resisted.

The question is not "is the colon redundant?" but "is the colon useful
despite, or even because, its redundancy?". There are two schools of
thought:

(1) Yes, it is useful, *because* of its redundancy -- it helps the human
reader parse and comprehend the source code.
Evidence given: usability studies by the ABC project.

(2) No, it is not useful, because the computer parser doesn't need it.
Evidence given: "it seems to me" repeated loudly until our ears bleed.

People's intuition is notoriously poor at judging usability. I don't say I
give it zero credence, but I give it very little.

[Antoon Pardon]

Post by Steven D'Aprano
Redundancy is not something to be valued for its own sake. It is only
valuable when it actually gains you something.

In the same way it is not something to be eliminated for its own
sake.

On the contrary, redundancy implies more work somewhere: e.g. more work
for the parser, more effort needed by the python-dev crew, bigger
binaries, larger code bases, more complex test suites, slower development,
longer downloads. Whatever the nature of the redundant thing, there will
be a cost to it. If that cost isn't outweighed by some advantage it should
be eliminated merely because it is redundant and therefore a cost we could
do without.

It you want to put it in those terms fine. It doesn't change the fact
that when someone doesn't like some proposal that happens to introduce
redundancy here in c.l.p, there is a reasonable chance that the proposal
will be dismissed with the simple observation that it introduces redundancy
without further reference to possible costs or benefits of the specific
redundancy.

IME there is a lot of redundancy that has benefits. So there is no
reason to dismiss a proposal simply on the grounds that it introduces
some redundancy. Something that seems to happen a lot here.

[Carl Banks]

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

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

Well, Python *is* quite a notorious redundancy minimizer....


Carl Banks

[Antoon Pardon]

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

Why are you trying to remove redundancy?

Why not? My impression is that removing redundancy is considered
a positive thing here in c.p.l.

The language is designed for
communication between people (programmers) primarily. Redundancy is
often the best way to be explicit and readable.

Except if you argue for blockmarkers. Then you get the response
that indentation is clear enough and such markers are redundant.

And there have been other subjects where redundancy was seen
as something negative.

[Michael Hobbs]

Post by Ron Adam

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.

Ron> I wasn't that specific and it was related to Michael's suggestion
Ron> the colon wasn't needed. If the need for '\' was dropped in
Ron> multi-line block headers, then the colon would be required for an
Ron> obvious reason.
x = a + \
b
not just conditionals.
Skip

Of course, and your point is?
How about if it be ok to continue to use '\' in headers, but it also be ok to
not to? That would be the backward compatible way to change it.
This doesn't answer the question I was asking, are there any situation where it
would cause problems? And if so, that reason would be a good and explicit
reason for not making such a change

To be clear, this is the actual thrust of my argument. It seems
redundant to have *both* line continuations and colons in compound
statements. I've been arguing for the removal of colons, though to be
honest, I'd be content with the opposite approach as well.

- Mike

[Ron Adam]

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

[Ron Adam]

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.

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

[Steven D'Aprano]

Post by Michael Hobbs

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*

[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

[Steven D'Aprano]

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

[Steven D'Aprano]

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

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.

[skip]

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

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

[Georg Brandl]

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

Eh? So multi-line strings are special enough to create a new syntax,
like, say, triple-quoted strings? Very long expressions aren't special
enough to create a special backslash token to continue the expression on
the next line? Multiple short expressions aren't special enough to
create a special semi-colon token to combine them on a single line?

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

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

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

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

Georg

[skip]

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

[Ron Adam]

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]

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

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

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

[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

[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

[Marc 'BlackJack' Rintsch]

In <mailman.1983.1163089419.11739.python-list at python.org>, Michael Hobbs

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

[Christophe]

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

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.

[Fredrik Lundh]

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

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

color = "blue"

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

</F>

[Dan Lenski]

Post by Hendrik van Rooyen
8<---------------------------------------------------

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

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

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

Dan

[Fredrik Lundh]

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>

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

On 9 Nov 2006 22:48:10 -0800, "John Henry" <john106henry at hotmail.com>

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

On 8 Nov 2006 11:49:07 -0800, "John Henry" <john106henry at hotmail.com>

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

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.

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.

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.

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.

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.

[Jussi Salmela]

Post by John Henry
http://prdownloads.sourceforge.net/pythoncard/testNotebook.zip?download
and tried it out. There is one error in the widget.py that I have to
canvas.setFillColor('gray')
canvas.setFillColor('gray')
pass
and then ran it. Works!
So, yes, you can do Notebook in Python. I believe what they are saying
is that Notebook isn't supported fully (yet) in the resourceeditor.

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

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

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

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

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

Cheers,
Jussi

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

[Jeremy Sanders]

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

[Neil Cerutti]

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.

[Hendrik van Rooyen]

have anyone counted the number of colons used in this way by the OP,
in his first few posts ? (if there isn't a name for the law that
states that the number for a "let's remove the colons" proposal is
always greater than zero, someone should come up with one...)

You just have - how do you want it to be immortalised?

The effbot's law of colonic inevitability?

- Badger (for Steve)

[Ron Adam]

I'm always surprised by the amount of energy that's put into this type
of discussion - even the OP has suggested that this isn't a big issue.
If it's not a big issue why is this thread still going? Every language
has a syntax. Why not just accept it as a given and get on with more
productive activities?

It's because it's not an issue with an obviously (clear to everyone) good or bad
answer.

Obvious bad answer -> short discussion

Obvious good answer -> short discussion which spawns many long discussion
about the not so obviously details.

* Nearly a toss up -> really long discussion that rehashes things over and
over from various micro points of view.

Even though it's pretty much known this won't change, people still want the
clarity of an obvious answer even if an obvious solution doe not exist, so the
thread continues. And of course what is obvious or not isn't obvious to
everyone, so that too is a long discussion. ;-)

But I think this thread has a second underlying attribute that appeals to the
participants. It isn't so much an effort to change anything as it is an effort
to explore and understand why things where made the way they are. To those who
already know, this seems silly, but to those who are still learning, it seems
important.

This could be broken down a bit more, but then we would get into long debates on
the best non-obvious ways to do that. ;-)

Cheers,
Ron

[Antoon Pardon]

Post by Fredrik Lundh

Anyway, the FAQ answer seems to be a weak argument to me.

I agree. I was expecting something more technical to justify the
colon, not just that it looks better.

yeah, the whole idea of treating programming languages as an interface
between people and computers is really lame. no wonder nobody's using
Python for anything.
</F>

personally, i don't mind the colon and see no need to lose it, but if we
are talking in the realm of aesthetics, it actually seems like it would
be cleaner if it weren't there...sure, at first everyone who is used to
it might feel like something is missing, or the line is "hanging" open,
but overall the less characters, the better, right? isn't that why the
braces are gone?

No. The braces are gone because they don't assist a reader's
determination of block structure like indentation does.

IMO this works both ways.

Otherwise why
would people write indenting pretty printers for C and the like?

Try to follow an indentation marked structure when the structure
crosses a page boundary and you can't view the whole structure
at once. Sensible placed markers can greatly assist in getting
a feel for a structure even if the structure is already properly
indented.

[Fredrik Lundh]

Steve Holden wrote:

y is this thread still going?

http://www.bikeshed.org/

I deliberately avoided using that analogy, but I'm sorry to say it
*does* apply. I'd hate to see c.l.py descend to becoming a wibble group.

I switched to a reader that lets me kill threads with a single keypress
a long time ago. which makes me wonder why I saw Magnus post and your
followup. wait a second...

[Robert Kern]

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

[Steve Holden]

Post by Fredrik Lundh

Anyway, the FAQ answer seems to be a weak argument to me.

I agree. I was expecting something more technical to justify the
colon, not just that it looks better.

yeah, the whole idea of treating programming languages as an interface
between people and computers is really lame. no wonder nobody's using
Python for anything.
</F>

personally, i don't mind the colon and see no need to lose it, but if we
are talking in the realm of aesthetics, it actually seems like it would
be cleaner if it weren't there...sure, at first everyone who is used to
it might feel like something is missing, or the line is "hanging" open,
but overall the less characters, the better, right? isn't that why the
braces are gone?

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

regards
Steve

[Magnus Lycka]

personally, i don't mind the colon and see no need to lose it, but if we
are talking in the realm of aesthetics, it actually seems like it would
be cleaner if it weren't there...sure, at first everyone who is used to
it might feel like something is missing, or the line is "hanging" open,
but overall the less characters, the better, right? isn't that why the
braces are gone?

Which is the better writing style for text intended for human readers?

I have some things to say:
Seagulls belong in the sky.
Colon fits in the text.

I have some things to say
{
Seagulls belong in the text.
Colon fits in the belly.
}

[Tim Chase]

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

[skip]

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

[Neil Cerutti]

Post by Robert Kern

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.

;-)

[Neil Cerutti]

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

[Steven D'Aprano]

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.

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

On 8 Nov 2006 11:49:07 -0800, "John Henry" <john106henry at hotmail.com>

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

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.

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.

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.

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.

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]

On 9 Nov 2006 22:48:10 -0800, "John Henry" <john106henry at hotmail.com>

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

On 8 Nov 2006 11:49:07 -0800, "John Henry" <john106henry at hotmail.com>

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

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.

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.

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.

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.

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.

[Wojciech Muła]

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

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

[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

[Eric Brunel]

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.

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

[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

[Steve Holden]

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

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?

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

red

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

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

regards
Steve

[Bjoern Schliessmann]

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

[Carsten Haese]

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?
Thanks,
- Mike

It is a very good idea as the colon is technically redundant (not
necessary for parsing, aside from one liners) and actually hurts
readability (and writeability). The "evidence" people cite for the
advantage of using a colon is research done by users of the ABC
language, python's predecessor. They forget that A) that was like 20
years ago,

Research being old does not automatically invalidate it. Old research is
invalidated by newer research that invalidates it.

B) the language was designed for children,

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

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

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

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

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

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

-Carsten

[Christophe]

Well, I *hate* underscores with a passion. So it is kinda frustrating
that I *have* to say "__init__". The fact that the coding conventions
for Python suggest things such as methods_called_this_or_that do not
help. Everything else seems fine, since if there's voodoo involved, it
had best be sticking out from the text in big, bloody, blinking, red
letters.
I know, there's noone preventing me from doing otherwise (except for
that blasted __init__). I'd like to follow the pack here, tho.

I'm sure a carefully crafted metaclass can be used to automaticaly
convert any init function to __init__ ;)

[sjdevnull]

No, old research does is not automatically invalidated, but
out-of-context research is. I'm sure there's research somewhere proving
that code written in ALL UPPERCASE is preferable, since it makes
punched-cards easier to read by humans. Python 1.0 may have been a nice
language for "newbies", with a lot of similarities to ABC, but there has
been a lot of evolution since then. Sure, it's still very easy to teach
basic Python, but if you're concerned about readability, take a look at
any real-world Python app or library. You'll find it's filled with
things such as "__getattr__", "__repr__", "__nonzero__", and
"super(MyClass, self).__init__()". Hardly newbie stuff.

Really?

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

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

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

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

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

[Michael Hobbs]

Post by Carsten Haese

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?
Thanks,
- Mike

It is a very good idea as the colon is technically redundant (not
necessary for parsing, aside from one liners) and actually hurts
readability (and writeability). The "evidence" people cite for the
advantage of using a colon is research done by users of the ABC
language, python's predecessor. They forget that A) that was like 20
years ago,

Research being old does not automatically invalidate it. Old research is
invalidated by newer research that invalidates it.

No, old research does is not automatically invalidated, but
out-of-context research is. I'm sure there's research somewhere proving
that code written in ALL UPPERCASE is preferable, since it makes
punched-cards easier to read by humans. Python 1.0 may have been a nice
language for "newbies", with a lot of similarities to ABC, but there has
been a lot of evolution since then. Sure, it's still very easy to teach
basic Python, but if you're concerned about readability, take a look at
any real-world Python app or library. You'll find it's filled with
things such as "__getattr__", "__repr__", "__nonzero__", and
"super(MyClass, self).__init__()". Hardly newbie stuff.

I think waving the banner of ABC simplicity in the context of Py3K is
about as applicable as complaining that an RSS aggregator isn't written
in assembly. (An RSS aggregator is so far beyond being CPU-bound that
it's pointless to argue which language it should be written in.)

- Mike

[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

[Neil Cerutti]

On 2006-11-09, Bjoern Schliessmann

return 'primary'
:)

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

Python also supports it.

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!

[John Henry]

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]

On 8 Nov 2006 11:49:07 -0800, "John Henry" <john106henry at hotmail.com>

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?

[Steve Holden]

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

[Bjoern Schliessmann]

color = "blue"

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

Whoops. Okay.

Regards,


Bj?rn

[Peter Decker]

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.

[Neil Cerutti]

On 2006-11-09, 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.

[Ron Adam]

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

[Marc 'BlackJack' Rintsch]

On 2006-11-09, Bjoern Schliessmann

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

[Steven D'Aprano]

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]

On 2006-11-09, Bjoern Schliessmann

return 'primary'
:)

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

Python also supports it.

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

[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

[Tony Nelson]

In article <4rhku3FriokeU2 at mid.individual.net>,
Bjoern Schliessmann <usenet-mail-0306.20.chr0n0ss at spamgourmet.com>

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*nlsnews at georgea*lastname*.com
' <http://www.georgeanelson.com/>

[Steve Holden]

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

[Michael Hobbs]

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'

[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

[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

[Christophe]

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

[John Salerno]

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/