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

[skip]

>>>>I'm not sure why '\'s are required to do multi-line before the colon.
Special cases aren't special enough to break the rules.

Georg
A bit of a circular answer.

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

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

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

But \ is used to continue all sorts of statements/expressions, e.g.:

x = a + \
b

not just conditionals.

Skip

[Dan Lenski]

Hendrik van Rooyen wrote:

"Fredrik Lundh" <fr*****@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:

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

[Ron Adam]

sk**@pobox.com wrote:

>>>>I'm not sure why '\'s are required to do multi-line before the colon.
>>>Special cases aren't special enough to break the rules.
>>>>
>>>Georg
>>A bit of a circular answer.
>>>
>>Why the rule? -So not to break the rule?
>>
>You proposed to allow leaving off line continuation '\' only in the
>"if", "for" and "while" headers. This is a special case in my eyes.

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

But \ is used to continue all sorts of statements/expressions, e.g.:

x = a + \
b

not just conditionals.

Skip

Of course, and your point is?

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

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

Ron

[Doug]

Michael Hobbs wrote:

Can anyone find a flaw with this change in syntax?

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

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

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

Thanks,
- Mike

It is a very good idea as the colon is technically redundant (not
necessary for parsing, aside from one liners) and actually hurts
readability (and writeability). The "evidence" people cite for the
advantage of using a colon is research done by users of the ABC
language, python's predecessor. They forget that A) that was like 20
years ago, B) the language was designed for children, and C) the
keywords in ABC are IN ALL CAPS LIKE THIS (hurting readability and
writeability) and thus adding a colon obviously helps restore some
readability for users in that case but not in python's.

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

[Hendrik van Rooyen]

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

Hendrik van Rooyen wrote:

"Fredrik Lundh" <fr*****@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:

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

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

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

- Hendrik

[John Henry]

Nice example.
Jussi Salmela wrote:

John Henry wrote:

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

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

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

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

[Carsten Haese]

On Sat, 2006-11-11 at 23:18 -0800, Doug wrote:

Michael Hobbs wrote:

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

Thanks,
- Mike

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

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

B) the language was designed for children,

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

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

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

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

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

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

-Carsten

[Carsten Haese]

On Sat, 2006-11-11 at 23:18 -0800, Doug wrote:

Michael Hobbs wrote:

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

Thanks,
- Mike

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

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

B) the language was designed for children,

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

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

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

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

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

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

-Carsten

[Carsten Haese]

On Sat, 2006-11-11 at 23:18 -0800, Doug wrote:

Michael Hobbs wrote:

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

Thanks,
- Mike

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

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

B) the language was designed for children,

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

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

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

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

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

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

-Carsten

[Simon Brunning]

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

Hendrik van Rooyen wrote:

blue is red or green or yellow

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

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

Indeed.

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

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

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

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

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

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

[Michael Hobbs]

Steven D'Aprano wrote:

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.

I was using the term "natural language" in a wider sense, as in spoken
languages, unspoken languages (sign languages), and writing systems. As
far redundancies in writing systems go, it has been estimated that there
is ~50% redundancy in the characters alone. That is, you can usually
determine what a character is even when half of its strokes are removed.
That's not even considering other redundancies such as using a phonetic
alphabet vs. ideographs, or writing the vowels between consonants, which
only started with the Greek alphabet.

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

I'd rather read neither. Both of them are obviously illegible. As the
saying goes, you can write FORTRAN code in any language. That is, no
language, no matter what its parsing rules, can prevent you from writing
illegible code if you're determined to do so. To me, the second example
is no more legible simply because it contains a colon somewhere. Proper
style would dictate that you make some form of obvious break when
writing a multi-line conditional, no matter which language you're using.
Some possibilities:

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
or

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
or

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:
#### BODY ####
and we can get to the business
of executing the while-block

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

Is Python a cult, where it's considered dangerous to experience the
outside world out of fear that it may corrupt your mind and make you
question all sorts of long-standing edicts?

If you're concerned about coddling inexperienced programmers, maybe you
should join Java cult. I hear that it is much more "safe" ;-)

- Mike

[John Salerno]

Fredrik Lundh wrote:

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>

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?

[Michael Hobbs]

Antoon Pardon wrote:

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.

As they say, insanity is nothing more than having a minority opinion. As
more people take the opposite side, who's left being the crazy one? ;-)

- Mike

[Michael Hobbs]

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

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?

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

- Mike

[Michael Hobbs]

Ron Adam wrote:

sk**@pobox.com wrote:

> >>>>I'm not sure why '\'s are required to do multi-line before the colon.
>>>Special cases aren't special enough to break the rules.
>>>>
>>>Georg
>>A bit of a circular answer.
>>>
>>Why the rule? -So not to break the rule?
>>
>You proposed to allow leaving off line continuation '\' only in the
>"if", "for" and "while" headers. This is a special case in my eyes.

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

But \ is used to continue all sorts of statements/expressions, e.g.:

x = a + \
b

not just conditionals.

Skip

Of course, and your point is?

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

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

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

[Michael Hobbs]

Carsten Haese wrote:

On Sat, 2006-11-11 at 23:18 -0800, Doug wrote:

>Michael Hobbs wrote:

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

Thanks,
- Mike

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

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

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

[Michael Hobbs]

Ron Adam wrote:

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.

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.

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]

Michael Hobbs wrote:

Ron Adam wrote:

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

I find if I approach things on a learning basis and always presume there are
things I still don't know. I then tend to get much more help and support than
if I approach things on a 'I'm right/your wrong' basis. Also, if I do turn out
to have a point a view that is not exactly right, it is then much easier for me
to take a new position or even the reverse position and move on.

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.

No one said (that I know of) that readability is *the primary objective*. But
it is a very important guideline.

>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

I believe you will find that exercise much more difficult than it seems, but I
may be wrong. Good luck if you try it, and let me know how it goes.

Ron

[Michael Hobbs]

Ron Adam wrote:

Michael Hobbs wrote:

>Ron Adam wrote:

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

I find if I approach things on a learning basis and always presume there are
things I still don't know. I then tend to get much more help and support than
if I approach things on a 'I'm right/your wrong' basis. Also, if I do turn out
to have a point a view that is not exactly right, it is then much easier for me
to take a new position or even the reverse position and move on.

To clarify my position, I'm not intentionally being contradictory. In
fact, when I first posed my question, I asked if anyone had a good
reason for why the redundancy should continue to exist. Expecting to get
a nice grammatical counter-example, the only viable answer that anyone
could come up with is the FAQ answer that it improves readability. Since
then, I've been fighting my point that the colon really doesn't improve
readability all that much.

In the end, I have to admit that I really couldn't give a flying frog if
the colon is there or not. It's just a colon, after all. I *was* hoping
that I could convince someone to honestly think about it and consider if
the colon is really that noticeable. But so far, the only response that
I've received is that there's that ABC study somewhere and that settles
that.

- Mike

[Ben Finney]

John Salerno <jo******@NOSPAMgmail.comwrites:

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 fewer characters, the better" is not right. Such absolutes
are to be avoided.

Sometimes, as in the case of omitting block-enclosing braces, removing
characters results in better readability. Other times, as in the case
of explicit names for objects, *more* characters results in better
readability -- but only up to a point.

Readability doesn't vary directly or inversely with the number of
characters, even though it is affected when they change.

--
\ "I bought a self learning record to learn Spanish. I turned it |
`\ on and went to sleep; the record got stuck. The next day I |
_o__) could only stutter in Spanish." -- Steven Wright |
Ben Finney

[Robert Kern]

Michael Hobbs wrote:

In the end, I have to admit that I really couldn't give a flying frog if
the colon is there or not. It's just a colon, after all. I *was* hoping
that I could convince someone to honestly think about it and consider if
the colon is really that noticeable. But so far, the only response that
I've received is that there's that ABC study somewhere and that settles
that.

Empirical usability research carries a lot of weight. Certainly more so than
projection of personal preferences.

But for what it's worth, my personal preference is that having the colon is more
readable. Yours isn't. That's fine. Debating on that basis, however, is pretty
pointless.

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

[Georg Brandl]

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

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

[Ben Finney]

Michael Hobbs <mi**@hobbshouse.orgwrites:

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.

--
\ "I was in the first submarine. Instead of a periscope, they had |
`\ a kaleidoscope. 'We're surrounded.'" -- Steven Wright |
_o__) |
Ben Finney

[Ron Adam]

Michael Hobbs wrote:

Ron Adam wrote:

>sk**@pobox.com wrote:

>> >>>>I'm not sure why '\'s are required to do multi-line before the colon.
>>>Special cases aren't special enough to break the rules.
>>>>
>>>Georg
>>A bit of a circular answer.
>>>
>>Why the rule? -So not to break the rule?
>>
>You proposed to allow leaving off line continuation '\' only in the
>"if", "for" and "while" headers. This is a special case in my eyes.

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

But \ is used to continue all sorts of statements/expressions, e.g.:

x = a + \
b

not just conditionals.

Skip

Of course, and your point is?

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

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

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

Well, maybe you should consider working on that instead. I think you will get
much less resistance.
Consider the following points:

* There are not (that I know of) any true multiple line block headers in python
but only long block headers with continued lines.

* It's probably more beneficial to simplify the more complex cases of multiple
continued lines, than it is to simplify the already simple cases of non
continued block headers.

* The block header can be identified in all cases by the initiating keyword and
the terminating colon. (colons in lambda and dicts need to be identified first)

* The block header can not always be clearly identified strictly based on
indenting as indenting in a block header spanning several lines is completely
optional and may vary quite a bit depending on the programmers preferences.

* Line continuations are *already* currently optional in other situations.

>>a = (1,

.... 1,
.... 3,
.... 4,
.... 5)

>>a

(1, 1, 3, 4, 5)

>>b = (6, \

.... 7, \
.... 8, \
.... 9)

>>b

(6, 7, 8, 9)
* Making line continuations optional requires no changes to the existing library.

* Removing colons would require changing block headers for all existing programs
and pythons library unless you made the ending colon optional. But that
probably would create more confusion and hurt readability more than it improves it.
So giving these points, and any others you can think of, which do you suppose
has a better chance of being implemented?

It also needs to be pointed out that the line continuations are a strong visual
indication that a line is continued and not just a aid to the compiler. So
there will be resistance to changing that also. (Over and above the general
resistance to change most people have.)

Cheers,
Ron

[Michael Hobbs]

Robert Kern wrote:

Michael Hobbs wrote:

>In the end, I have to admit that I really couldn't give a flying frog if
the colon is there or not. It's just a colon, after all. I *was* hoping
that I could convince someone to honestly think about it and consider if
the colon is really that noticeable. But so far, the only response that
I've received is that there's that ABC study somewhere and that settles
that.

Empirical usability research carries a lot of weight. Certainly more so than
projection of personal preferences.

Yes, but all we have is a passing mention of it in the FAQ. If someone
could actually find the full content of the study and show that it is
[still] relevant to Python, I'd give it a lot of weight too. As it
stands, I've become far too jaded by so-called "studies" (both technical
and medical) to accept them on blind faith.

But for what it's worth, my personal preference is that having the colon is more
readable. Yours isn't. That's fine. Debating on that basis, however, is pretty
pointless.

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.

- Mike

[John Salerno]

Ben Finney wrote:

No. "The fewer characters, the better" is not right. Such absolutes
are to be avoided.

Sometimes, as in the case of omitting block-enclosing braces, removing
characters results in better readability. Other times, as in the case
of explicit names for objects, *more* characters results in better
readability -- but only up to a point.

Ok, true, but there seems (to me) to be a difference between
content-related characters, such as giving more descriptive names to
variables, and syntax-related characters, such as colons and braces. I
was thinking strictly of the language syntax and not necessarily about
making the code quite literally more readable (with real words for
variables instead of 'x', or 'timv' instead of 'this_is_my_variable').

[Ron Adam]

Michael Hobbs wrote:

Ron Adam wrote:

>Michael Hobbs wrote:

>>Ron Adam wrote:

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.

I find if I approach things on a learning basis and always presume there are
things I still don't know. I then tend to get much more help and support than
if I approach things on a 'I'm right/your wrong' basis. Also, if I do turn out
to have a point a view that is not exactly right, it is then much easier for me
to take a new position or even the reverse position and move on.

To clarify my position, I'm not intentionally being contradictory. In
fact, when I first posed my question, I asked if anyone had a good
reason for why the redundancy should continue to exist. Expecting to get
a nice grammatical counter-example, the only viable answer that anyone
could come up with is the FAQ answer that it improves readability. Since
then, I've been fighting my point that the colon really doesn't improve
readability all that much.

And you may be entirely correct that it doesn't improve readability "that much"
or not enough to matter. So at some point some body made a choice and now that's
what we have.

But the situation of readability now is influenced by that choice made then. If
it was a close call when abc was designed, enough so that a study was needed to
decide, It has now become what we are used to. And familiarity probably has a
bigger effect on readability.

In the end, I have to admit that I really couldn't give a flying frog if
the colon is there or not. It's just a colon, after all. I *was* hoping
that I could convince someone to honestly think about it and consider if
the colon is really that noticeable. But so far, the only response that
I've received is that there's that ABC study somewhere and that settles
that.

- Mike

As I said above, it may in fact be the way it is, simply because someone at some
point made a choice for what ever reason they had at the time. But changing
this particular item at this time isn't something that would be practical. (my
opinion) So probably the best you can expect is for a few people to agree with
you. Which is fine.

If enough people were to agree with you, you could start a group effort to write
your own version of python and distribute that. There's nothing preventing
anyone from doing that.

Cheers,
Ron

[sjdevnull]

Michael Hobbs wrote:

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.

[Steve Holden]

John Salerno wrote:

Fredrik Lundh wrote:

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

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

Michael Hobbs wrote:

Carsten Haese wrote:

>On Sat, 2006-11-11 at 23:18 -0800, Doug wrote:

>>Michael Hobbs wrote:

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

Thanks,
- Mike

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

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

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.

In fact most Python doesn't use such constructs, though I'll admit the
occasional __init__ is more or less inevitable once you start using the
object-oriented features more than casually.

You are talking about some fairly advanced introspection, and the double
under naming conventions were chosen precisely to indicate that some
fairly special voodoo was being invoked. Readability is relative, and by
the time you have the need to use the magic names they probably won't
interfere with your reading overmuch.

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

I might take your admittedly cheerful wibbling a little more seriously
if, rather than trying to argue that the ABC study isn't valid for
Python, you came up with some sort of result that supported your ideas
(which I accept you aren't really concerned to promote: does this make
you a troll?)

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

[Robert Kern]

Michael Hobbs wrote:

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.

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

[skip]

MikeBut so far, the only response that I've received is that there's
Mikethat ABC study somewhere and that settles that.

In the absence of a later study that refutes the ABC work, I think it's best
left alone.

Skip

[Michael Hobbs]

Robert Kern wrote:

Michael Hobbs wrote:

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

Now I see where we disagree. Also gaging from everyone else's reaction,
I must have some strange no-colon circuitry wired into my brain.

I guess that's it then,
- Mike

[Dan Lenski]

Ben Finney wrote:

Readability doesn't vary directly or inversely with the number of
characters, even though it is affected when they change.

Good point! Perl has more characters than Python, and I find they make
it harder to read because they are distracting.

Brainf*** (http://en.wikipedia.org/wiki/Brainf***) only has 8 possible
characters, and it's hard to read because you can't easily recognize
repeating patterns or features.

I think this is something that typographers have been studying for
hundreds of years, how changing the shape of characters, page layout,
and typographical conventions affect the ability to easily read and
comprehend text. I know that in college I hated one physics textbook
which used monospaced fonts... it was well-written but just hurt my
eyes to browse through.

Dan

[Carl Banks]

Steve Holden wrote:

In fact most Python doesn't use such constructs, though I'll admit the
occasional __init__ is more or less inevitable once you start using the
object-oriented features more than casually.

Occasional? I don't know about you, but I use __init__ in 99% of the
classes I define. :) I don't think __special_symbols__ are manifestly
unsuitable for newbies--they're just special.

I was curious how much I used these symbols. For my current largish
project:

306 __init__
68 __future__
44 __dict__
3 __name__
3 __main__
3 __import__
3 __builtin__
2 __str__
2 __file__
1 __setitem__
1 __setattr__
1 __repr__
1 __or__
1 __ne__
1 __int__
1 __getitem__
1 __getattribute__
1 __eq__
1 __call__
1 __add__

Excepting my use of __dict__, not a whole lot advanced usage there, and
I am NOT the kind of person who's afraid to do advanced things when
it's useful. Much of the advanced stuff, including __dict__, is for
debugging. (I have a lot of classes that acquire resources that I must
explicity release, so I clear the __dict__ to catch any post-release
accesses, which could cause subtle failures otherwise.)
Carl Banks

[Carl Banks]

Ben Finney wrote:

Michael Hobbs <mi**@hobbshouse.orgwrites:

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

[Hendrik van Rooyen]

"Simon Brunning" <si***@brunningonline.netWrote:

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

Hendrik van Rooyen wrote:

>blue is red or green or yellow
>
*grin* - this can be construed as a weakness in Python -

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

Indeed.

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

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

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

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

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

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

[Hendrik van Rooyen]

"Robert Kern" <ro*********@gmail.comwrote:

Michael Hobbs wrote:

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!

- Hendrik

[Antoon Pardon]

On 2006-11-13, Steve Holden <st***@holdenweb.comwrote:

John Salerno wrote:

>Fredrik Lundh wrote:

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

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.

--
Antoon Pardon

[Antoon Pardon]

On 2006-11-13, Ben Finney <bi****************@benfinney.id.auwrote:

Michael Hobbs <mi**@hobbshouse.orgwrites:

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

--
Antoon Pardon

[Fredrik Lundh]

Antoon Pardon wrote:

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

so why are you still here?

</F>

[Antoon Pardon]

On 2006-11-14, Fredrik Lundh <fr*****@pythonware.comwrote:

Antoon Pardon wrote:

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

so why are you still here?

Because I have a different opinion and I don't need your permission.

--
Antoon Pardon

[Dan Lenski]

Hendrik van Rooyen wrote:

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

Unfortunately natural language is completely riddled with ambiguities
about negation and conjunction. It doesn't seem like a good idea for
programming languages to emulate these too closely, even if it does
make for more "natural" constructions.

For example:
"You must not go there." means "You are forbidden to go there."
"You do not have to go there." means "You are not required to go
there."
Similar negations of two English verbs with virtually identical meaning
makes quite a difference in the semantics of the complete sentence!

Likewise, double negation is perfectly equivalent to single negation in
many languages, including in some dialects of English:
"I ain't got time." means "I don't have time."
"I ain't got no time." means "I don't have time."

Another problem is that the English word "or" sometimes means
"inclusive or" and sometimes means "exclusive or":
"Do you have any brothers or sisters?" (inclusive or)
"You can carry on a briefcase or a backpack." (exclusive or)

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

Dan

[Robert Kern]

Hendrik van Rooyen wrote:

"Robert Kern" <ro*********@gmail.comwrote:

>Michael Hobbs wrote:

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

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

[skip]

>>Michael Hobbs wrote:

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

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

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

If your editor knows about Python's block structure (as Emacs's python-mode
does), when you forget the colon it's immediately obvious because the next
line doesn't autoindent properly.

Skip

[Terry Reedy]

<sk**@pobox.comwrote in message
news:17**********************@montanaro.dyndns.org ...

>I confess I find myself in the position of a Yorkshire Youngster -

I

>don't believe you!

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

If your editor knows about Python's block structure (as Emacs's
python-mode
does), when you forget the colon it's immediately obvious because the
next
line doesn't autoindent properly.

The same is true of the editor in IDLE.

[Stephen Eilert]

Carl Banks escreveu:

Steve Holden wrote:

In fact most Python doesn't use such constructs, though I'll admit the
occasional __init__ is more or less inevitable once you start using the
object-oriented features more than casually.

Occasional? I don't know about you, but I use __init__ in 99% of the
classes I define. :) I don't think __special_symbols__ are manifestly
unsuitable for newbies--they're just special.

I was curious how much I used these symbols. For my current largish
project:

306 __init__
68 __future__
44 __dict__
3 __name__
3 __main__
3 __import__
3 __builtin__
2 __str__
2 __file__
1 __setitem__
1 __setattr__
1 __repr__
1 __or__
1 __ne__
1 __int__
1 __getitem__
1 __getattribute__
1 __eq__
1 __call__
1 __add__

Excepting my use of __dict__, not a whole lot advanced usage there, and
I am NOT the kind of person who's afraid to do advanced things when
it's useful. Much of the advanced stuff, including __dict__, is for
debugging. (I have a lot of classes that acquire resources that I must
explicity release, so I clear the __dict__ to catch any post-release
accesses, which could cause subtle failures otherwise.)
Carl Banks

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

[Hendrik van Rooyen]

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

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

[Steven D'Aprano]

On Tue, 14 Nov 2006 12:01:05 +0000, Antoon Pardon wrote:

On 2006-11-13, Ben Finney <bi****************@benfinney.id.auwrote:

>Michael Hobbs <mi**@hobbshouse.orgwrites:

>>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.
--
Steven D'Aprano

[Antoon Pardon]

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

On Tue, 14 Nov 2006 12:01:05 +0000, Antoon Pardon wrote:

>On 2006-11-13, Ben Finney <bi****************@benfinney.id.auwrote:

>>Michael Hobbs <mi**@hobbshouse.orgwrites:

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 in whatever proposal the opponent doesn't like.

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. But if someone doesn't like a particulare proposal and
the proposal happens to introduce some redundancy then there is
a reasonable chance the proposal will be dismissed by simply
observing that it introduces redundancy.

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.

I wonder, did this project also studied the readability of:

if a == b then

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

A pity that no such study seems to exists concerning code that uses
only indentation to mark structure and code that uses indentation
and some kind of delimiter for showing the boundaries of (sub)
structures. Because the evidence for end markers not being usefull
seems to fall in the same category as (2) here above.

--
Antoon Pardon