How to choose the right GUI toolkit ?

[Dan Lenski]

Hi all,
I'm a recent, belated convert from Perl. I work in a physics lab and
have been using Python to automate a lot of measurement equipment
lately. It works fabulously for this purpose. Recently I've wanted to
start writing GUIs for some of my programs, for data visualization and
to make the programs easier to use for some of my co-workers.

So far I've experimented with two Python GUI toolkits: Tkinter and
PyGTK. I've had some issues with each:

* PyGTK - not very "pythonic", in my opinion. Have to use get_ and
set_ methods rather than properties. Have to write ugly things like
textview.insert(textview.get_end_iter(), ...) to append text to a text
buffer. No useful doc strings, which makes experimenting with new
widgets in IPython a huge pain. The toolkit feels very "heavyweight".
I don't want to write an XML file and an "action group" just to make a
piddly little menubar with 10 items.

I'm an avid Gnome fan, and love the professionalness and completeness
of GTK, but PyGTK seems frustratingly C-like compared to the
wonderfully designed high-level abstractions I've come to love in
Python!

* TkInter - Seems easy to learn, and better for quick "lightweight"
GUIs. I wrote a complete working instrument GUI in less than a day of
figuring things out. Not very Pythonic in terms of creating and
modifying widgets. No factory functions to quickly create menu items.
My biggest problem with Tkinter is that it is very unreliable under
Cygwin: programs freeze and slow intermittently and the tkMessageDialog
stock dialog boxes show no visible text.

So, is there another toolkit I should be looking at? Having something
that can run easily on Cygwin and native Windows is a priority so that
I can quickly move programs to new measurement computers. I like GTK a
lot and Tk is growing on me too.. are there any higher-level "wrapper"
toolkits for GTK and Tk?

Thanks for any advice!

Dan Lenski
University of Maryland

[Robert Kern]

sk**@pobox.com wrote:

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!

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Tony Nelson]

In article <4r************@mid.individual.net>,
Bjoern Schliessmann <us**************************@spamgourmet.com>
wrote:

Michael Hobbs wrote:

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'

What about

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

What about

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

[Michael Hobbs]

Ben Finney wrote:

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.

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

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.

>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

[Neil Cerutti]

On 2006-11-10, Bjoern Schliessmann <us**************************@spamgourmet.comwrote :

Neil Cerutti wrote:

>On 2006-11-09, Bjoern Schliessmann

>>if color == red or blue or green:
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!

--
Neil Cerutti

[Neil Cerutti]

On 2006-11-10, Robert Kern <ro*********@gmail.comwrote:

sk**@pobox.com wrote:

>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
Scouts are saving aluminum cans, bottles, and other items to be
recycled. Proceeds will be used to cripple children. --Church Bulletin
Blooper

[Marc 'BlackJack' Rintsch]

In <4r************@mid.individual.net>, Bjoern Schliessmann wrote:

Neil Cerutti wrote:

>On 2006-11-09, Bjoern Schliessmann

>>if color == red or blue or green:
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

[skip]

Robertsk**@pobox.com wrote:

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

RobertYou did it just now!

Hence the smiley. ;-)

S

[Steve Holden]

Michael Hobbs wrote:

Ben Finney wrote:

[...]

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

The same problem that is solved by not having to type parens around the
'if' conditional, a la C and its derivatives. That is, it's unnecessary
typing to no good advantage, IMHO. I was coding in Ruby for several
months and got very comfortable with just typing the if conditional and
hitting return, without any extra syntax. When I came back to Python, I
found that I felt annoyed every time I typed the colon, since it
obviously isn't required. The FAQ says that the colon increases
readability, but I'm skeptical. The indentation seems to provide more
than enough of a visual clue as to where the if conditional ends.

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

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

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

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

[Steve Holden]

Bjoern Schliessmann wrote:

Michael Hobbs wrote:

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

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.

I still prefer

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

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

[Ron Adam]

Michael Hobbs wrote:

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

[Michael Hobbs]

Steve Holden wrote:

Michael Hobbs wrote:

>Ben Finney wrote:

[...]

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

The same problem that is solved by not having to type parens around the
'if' conditional, a la C and its derivatives. That is, it's unnecessary
typing to no good advantage, IMHO. I was coding in Ruby for several
months and got very comfortable with just typing the if conditional and
hitting return, without any extra syntax. When I came back to Python, I
found that I felt annoyed every time I typed the colon, since it
obviously isn't required. The FAQ says that the colon increases
readability, but I'm skeptical. The indentation seems to provide more
than enough of a visual clue as to where the if conditional ends.

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

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

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

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

Yeah, okay, I didn't read through the details of the PEP. I picked a bad
example to illustrate a point that is still true. The FAQ also tries to
argue that it's a Good Thing that join() is a string method, not a list
method. It also tries to argue that there's a good reason that lists are
different than tuples. I don't think it would surprising that many
Python developers don't really buy those arguments either.

- Mike

[skip]

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

>The FAQ says that the colon increases readability, but I'm
skeptical. The indentation seems to provide more than enough of a
visual clue as to where the if conditional ends.

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

# Oh, wait, I shouldn't have typed that colon just now! It's not
# necessary. Oh, darn. Hmmm... What does Strunk say?
if (some_long_expression and
some_other_long_expression and
yet_another_long_expression):
that_was_a_long_expression = True

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

Skip

[Michael Hobbs]

Ron Adam wrote:

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

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

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

- Mike

[Bjoern Schliessmann]

Marc 'BlackJack' Rintsch wrote:

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

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

Regards,
Björn

--
BOFH excuse #239:

CPU needs bearings repacked

[James Cunningham]

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

Marc 'BlackJack' Rintsch wrote:

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

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

Regards,
Björn

Yes, I'm not sure myself.

In [1]: color = "red"

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

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

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

[Fredrik Lundh]

John Salerno wrote:

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

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

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

</F>

[Fredrik Lundh]

Bjoern Schliessmann wrote:

Marc 'BlackJack' Rintsch wrote:

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

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

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

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

</F>

[Max Erickson]

>>color='orange'

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

print "Works?"
Works?

>>>

[James Cunningham]

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

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

print "Works?"
Works?

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

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

Best,
James

[Ron Adam]

Michael Hobbs wrote:

Ron Adam wrote:

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

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

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

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

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

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

xxx xxx:
yyy yyy
yyy yyy

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

It is also an outline form that frequently used in written languages. Something
python tries to do, is to be readable as if it were written in plain language
where it is practical to do so. So the colon/outline form makes a certain sense
in that case as well.

Cheers,
Ron

[Steve Holden]

James Cunningham wrote:

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

>Marc 'BlackJack' Rintsch wrote:

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

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

Regards,
Björn

Yes, I'm not sure myself.

In [1]: color = "red"

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

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

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

Try testing a little more completely:

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

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

>>>

Still think it works?

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

red

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

True

>>>

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

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Michael Hobbs]

Ron Adam wrote:

It is also an outline form that frequently used in written languages. Something
python tries to do, is to be readable as if it were written in plain language
where it is practical to do so. So the colon/outline form makes a certain sense
in that case as well.

That is perhaps the most convincing argument that I've heard so far.
Indeed, I often find myself writing out colons when writing pseudo-code
out on paper. The reason, however, is usually because my indents don't
quite line up as perfectly on paper as they do in an editor. The colons
provide a form of backup separation for when my columns start to get
sloppy. (Natural language is actually filled with such redundancies in
order to compensate for sloppy handwriting.) This backup function
obviously isn't needed when a computer is taking care of the layout.

My final argument against the colons is to simply try programming in
Ruby for a while and then come back to Python. I think you'll find that
programming without the colons just simply feels more "natural".

- Mike

[Bjoern Schliessmann]

Fredrik Lundh wrote:

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

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

Whoops. Okay.

Regards,
Björn

--
BOFH excuse #303:

fractal radiation jamming the backbone

[Ron Adam]

Michael Hobbs wrote:

Ron Adam wrote:

>It is also an outline form that frequently used in written languages. Something
python tries to do, is to be readable as if it were written in plain language
where it is practical to do so. So the colon/outline form makes a certain sense
in that case as well.

That is perhaps the most convincing argument that I've heard so far.
Indeed, I often find myself writing out colons when writing pseudo-code
out on paper. The reason, however, is usually because my indents don't
quite line up as perfectly on paper as they do in an editor. The colons
provide a form of backup separation for when my columns start to get
sloppy. (Natural language is actually filled with such redundancies in
order to compensate for sloppy handwriting.) This backup function
obviously isn't needed when a computer is taking care of the layout.

My final argument against the colons is to simply try programming in
Ruby for a while and then come back to Python. I think you'll find that
programming without the colons just simply feels more "natural".

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

The point is what is more natural to "read" with a minimum amount of
explanation. I would think for most people who are learning programming for the
first time, it is things that resemble things they already know. Such as
outlining with colons.

Leaving the colon out probably would feel more natural for writing once you get
used to it. After all it is a bit less typing. But I don't think it would be
the most readable choice for most people. It's probably a trade off,
readability vs writability. Another python development guideline is to favor
readability over writability on the presumption we tend to write code once, but
read code many times.

Here's an alternative test. Write a program to remove all the end of line
colons from pythons library and then write another separate program to put them
back in. Will it miss any? will it pass the python test suite?

I think you will find that that is more complex than it sounds. Try writing
colorizing routines for both versions? Which is easier?

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

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

[Steven D'Aprano]

On Fri, 10 Nov 2006 21:24:50 +0100, Bjoern Schliessmann wrote:

Marc 'BlackJack' Rintsch wrote:

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

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

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

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

or if you prefer:

x in (blue, red, yellow)

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

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

--
Steven.

[Steven D'Aprano]

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

The FAQ says that the colon increases
readability, but I'm skeptical. The indentation seems to provide more
than enough of a visual clue as to where the if conditional ends.

and then in a later post:

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

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

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

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

[Steven D'Aprano]

On Fri, 10 Nov 2006 15:18:55 -0600, Michael Hobbs wrote:

Ron Adam wrote:

>It is also an outline form that frequently used in written languages. Something
python tries to do, is to be readable as if it were written in plain language
where it is practical to do so. So the colon/outline form makes a certain sense
in that case as well.

That is perhaps the most convincing argument that I've heard so far.
Indeed, I often find myself writing out colons when writing pseudo-code
out on paper. The reason, however, is usually because my indents don't
quite line up as perfectly on paper as they do in an editor. The colons
provide a form of backup separation for when my columns start to get
sloppy. (Natural language is actually filled with such redundancies in
order to compensate for sloppy handwriting.)

Er, natural language pre-dates handwriting by many tens or hundreds of
thousands of years. The redundancy of natural language has many reasons,
but compensating for sloppy handwriting is not one of them.

This backup function
obviously isn't needed when a computer is taking care of the layout.

That word you use, "obviously", I don't think it means what you think it
means. There's nothing obvious about your conclusion to me.

while (this really long expression
(which extends over multiple lines
and contains many statements)
some of which (like this one) contain
nested bracketed terms such as (this
expression here) but like all good
things) it eventually ends
and we can get to the business
of executing the while-block

Compare that to the version with a colon:

while (this really long expression
(which extends over multiple lines
and contains many statements)
some of which (like this one) contain
nested bracketed terms such as (this
expression here) but like all good
things) it eventually ends:
and we can get to the business
of executing the while-block
Arguably, the parser might not find the first version any more difficult
than the second, but I know which one I'd rather read.

My final argument against the colons is to simply try programming in
Ruby for a while and then come back to Python. I think you'll find that
programming without the colons just simply feels more "natural".

And maybe you're even correct. But one major reason of using the colon is
to make it easier for _inexperienced_ programmers. Your suggestion that
programming in Ruby for a while should be a prerequisite for making Python
easy to read is an interesting one, but not one that many people will
agree with. *wink*
--
Steven.

[James Cunningham]

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

[snip]

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

Dan

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

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

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

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

Best,
James

[Paul Boddie]

Ron Adam wrote:

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

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

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

;-)

Paul

[Steven D'Aprano]

On Fri, 10 Nov 2006 13:16:32 -0600, Michael Hobbs wrote:

Yeah, okay, I didn't read through the details of the PEP. I picked a bad
example to illustrate a point that is still true. The FAQ also tries to
argue that it's a Good Thing that join() is a string method, not a list
method. It also tries to argue that there's a good reason that lists are
different than tuples. I don't think it would surprising that many
Python developers don't really buy those arguments either.

Well, as far as I'm concerned, you've just blown your credibility
completely out the water now.

Yes, I'm aware that there are many Python programmers who don't get join()
or lists/tuples, but I'm constantly surprised by that fact. At the risk of
starting another argument, to my mind that's like discovering that there
are professional butchers who don't think that using a sharp knife is a
good idea.
--
Steven.

[Bjoern Schliessmann]

Steven D'Aprano wrote:

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)

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

Regards,
Björn

--
BOFH excuse #317:

Internet exceeded Luser level, please wait until a luser logs off
before attempting to log back on.

[Bill Maxwell]

On 9 Nov 2006 22:48:10 -0800, "John Henry" <jo**********@hotmail.com>
wrote:

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

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.

>
John Henry wrote:

>Bill Maxwell wrote:

On 8 Nov 2006 11:49:07 -0800, "John Henry" <jo**********@hotmail.com>
wrote:
John Salerno wrote:
Dan Lenski wrote:

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

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

#!/usr/bin/python

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

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

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

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.

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

from PythonCard import model, dialog

instead of just:

from PythonCard import model

I just tried it and it works.

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

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

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

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/Mai...oncard/2536825

and, that message led me here:

http://article.gmane.org/gmane.comp....ythoncard/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."

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.

[Peter Decker]

On 9 Nov 2006 09:13:00 -0800, Dan Lenski <dl*****@gmail.comwrote:

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.

--

# p.d.

[skip]

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

Where can I read about mushrooms as animals?

Skip

[Steven D'Aprano]

On Fri, 10 Nov 2006 22:41:53 -0600, skip wrote:

>
StevenThe world seems to be flat, the sun appears to rotate around the
StevenEarth, and mushrooms look like they are more closely related to
Stevenplants than to animals, but none of these things are actually
Steventhe 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.

[Hendrik van Rooyen]

"Fredrik Lundh" <fr*****@pythonware.comwrote:

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

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

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

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

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

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

[Ron Adam]

Steven D'Aprano wrote:

On Fri, 10 Nov 2006 21:24:50 +0100, Bjoern Schliessmann wrote:

>Marc 'BlackJack' Rintsch wrote:

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

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

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

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

Maybe it should have been expressed as:

x == (blue or red or yellow)
Cheers,
Ron

[Ron Adam]

Paul Boddie wrote:

Ron Adam wrote:

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

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

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

;-)

Paul

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

Ron

[Fredrik Lundh]

Michael Hobbs wrote:

Yeah, okay, I didn't read through the details of the PEP. I picked a bad
example to illustrate a point that is still true. The FAQ also tries to
argue that it's a Good Thing that join() is a string method, not a list
method. It also tries to argue that there's a good reason that lists are
different than tuples. I don't think it would surprising that many
Python developers don't really buy those arguments either.

nice try, troll boy.

</F>

[Fredrik Lundh]

Hendrik van Rooyen wrote:

>blue is red or green or yellow

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

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

</F>

[Antoon Pardon]

On 2006-11-11, Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:

On Fri, 10 Nov 2006 13:16:32 -0600, Michael Hobbs wrote:

>Yeah, okay, I didn't read through the details of the PEP. I picked a bad
example to illustrate a point that is still true. The FAQ also tries to
argue that it's a Good Thing that join() is a string method, not a list
method. It also tries to argue that there's a good reason that lists are
different than tuples. I don't think it would surprising that many
Python developers don't really buy those arguments either.

Well, as far as I'm concerned, you've just blown your credibility
completely out the water now.

Yes, I'm aware that there are many Python programmers who don't get join()
or lists/tuples, but I'm constantly surprised by that fact. At the risk of
starting another argument, to my mind that's like discovering that there
are professional butchers who don't think that using a sharp knife is a
good idea.

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.

--
Antoon Pardon

[Steven D'Aprano]

On Sat, 11 Nov 2006 01:13:03 -0600, Ron Adam wrote:

Steven D'Aprano wrote:

>On Fri, 10 Nov 2006 21:24:50 +0100, Bjoern Schliessmann wrote:

>>Marc 'BlackJack' Rintsch wrote:

No it doesn't -- look again at the example given above. It's
legal syntax in Python but doesn't have the semantics implied by
the example.
Sorry, I don't understand -- what is the difference between the
example as it is and the implied semantics of it?

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

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

Maybe it should have been expressed as:

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

[Florian Diesch]

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

So, is there another toolkit I should be looking at? Having something
that can run easily on Cygwin and native Windows is a priority so that
I can quickly move programs to new measurement computers. I like GTK a
lot and Tk is growing on me too.. are there any higher-level "wrapper"
toolkits for GTK and Tk?

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

Florian
--
<http://www.florian-diesch.de/>

[Ron Adam]

Steven D'Aprano wrote:

On Sat, 11 Nov 2006 01:13:03 -0600, Ron Adam wrote:

>Steven D'Aprano wrote:

>>On Fri, 10 Nov 2006 21:24:50 +0100, Bjoern Schliessmann wrote:

Marc 'BlackJack' Rintsch wrote:

No it doesn't -- look again at the example given above. It's
legal syntax in Python but doesn't have the semantics implied by
the example.
Sorry, I don't understand -- what is the difference between the
example as it is and the implied semantics of it?
Inform 6 "x == blue or red or yellow" is equivalent to the Python

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

Maybe it should have been expressed as:

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.

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

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

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

Cheers,
Ron

[Georg Brandl]

Ron Adam wrote:

Michael Hobbs wrote:

>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

[John Henry]

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

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

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

canvas.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.
Bill Maxwell wrote:

On 9 Nov 2006 22:48:10 -0800, "John Henry" <jo**********@hotmail.com>
wrote:

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.

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.

John Henry wrote:

Bill Maxwell wrote:
On 8 Nov 2006 11:49:07 -0800, "John Henry" <jo**********@hotmail.com>
wrote:

>
>John Salerno wrote:
>Dan Lenski wrote:
>>
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
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:


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

#!/usr/bin/python

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

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

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

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.


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

from PythonCard import model, dialog

instead of just:

from PythonCard import model

I just tried it and it works.


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


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

Not saying that there are 10 programmers working 7/24 on it. It *is*
an Open Source project nevertheless. Nobody gets paid for doing it.
But there are development work going on.
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/Mai...oncard/2536825

and, that message led me here:

http://article.gmane.org/gmane.comp....ythoncard/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."

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.

[Ron Adam]

Georg Brandl wrote:

Ron Adam wrote:

>Michael Hobbs wrote:

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

Ron Adam wrote:

Georg Brandl wrote:

>Ron Adam wrote:

>>Michael Hobbs wrote:

The same problem that is solved by not having to type parens around the
'if' conditional, a la C and its derivatives. That is, it's unnecessary
typing to no good advantage, IMHO. I was coding in Ruby for several
months and got very comfortable with just typing the if conditional and
hitting return, without any extra syntax. When I came back to Python, I
found that I felt annoyed every time I typed the colon, since it
obviously isn't required. The FAQ says that the colon increases
readability, but I'm skeptical. The indentation seems to provide more
than enough of a visual clue as to where the if conditional ends.

>>I'm not sure why '\'s are required to do multi-line before the colon.

Special cases aren't special enough to break the rules.

Georg

A bit of a circular answer.

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

You proposed to allow leaving off line continuation '\' only in the
"if", "for" and "while" headers. This is a special case in my eyes.

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

Explicit is better than implicit.

Of course, this always applies :)

Georg

[Ron Adam]

Georg Brandl wrote:

Ron Adam wrote:

>Georg Brandl wrote:

>>Ron Adam wrote:
Michael Hobbs wrote:

The same problem that is solved by not having to type parens around the
'if' conditional, a la C and its derivatives. That is, it's unnecessary
typing to no good advantage, IMHO. I was coding in Ruby for several
months and got very comfortable with just typing the if conditional and
hitting return, without any extra syntax. When I came back to Python, I
found that I felt annoyed every time I typed the colon, since it
obviously isn't required. The FAQ says that the colon increases
readability, but I'm skeptical. The indentation seems to provide more
than enough of a visual clue as to where the if conditional ends.
I'm not sure why '\'s are required to do multi-line before the colon.
Special cases aren't special enough to break the rules.

Georg

A bit of a circular answer.

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

You proposed to allow leaving off line continuation '\' only in the
"if", "for" and "while" headers. This is a special case in my eyes.

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

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

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

Ron

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

Explicit is better than implicit.

Of course, this always applies :)

Georg

[Jussi Salmela]

John Henry wrote:

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

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

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

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

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/