How to choose the right GUI toolkit ?

[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

 

[Michael Hobbs]

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

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

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]

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]

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

 

[Fredrik Lundh]

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>

 

[James Cunningham]

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]

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

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

</F>

 

[Max Erickson]

color='orange' print "Works?"


Works?

 

[James Cunningham]

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]

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]

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

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

regards
Steve

 

[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

 

[Bjoern Schliessmann]

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

Whoops. Okay.

Regards,


Björn

 

[Ron Adam]

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]

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 D'Aprano]

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.

 

[James Cunningham]

[snip]

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

Dan

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

http://wiki.wxwidgets.org/docbrowse.cgi/wxwin_wxplatforminfo.html

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

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

Best,
James

 

[Steven D'Aprano]

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*

 

[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