How to choose the right GUI toolkit ?

[Ben Finney]

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.

 

[Robert Kern]

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

 

[Ben Finney]

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.

 

[Georg Brandl]

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

 

[Ron Adam]

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.
.... 1,
.... 3,
.... 4,
.... 5)(1, 1, 3, 4, 5)
.... 7, \
.... 8, \
.... 9)(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]

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]

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]

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]

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]

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]

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

 

[Robert Kern]

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

Never.

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

Mike> But so far, the only response that I've received is that there's
Mike> that 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]

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]

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]

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]

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]

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]

Never.

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

- Hendrik

 

[Antoon Pardon]

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.