How to choose the right GUI toolkit ?

[Antoon Pardon]

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.

 

[Fredrik Lundh]

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]

so why are you still here?

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

 

[Dan Lenski]

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

 

[Hendrik van Rooyen]

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

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

- Hendrik

 

[Robert Kern]

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]

Robert> Okay, not often enough or annoyingly enough for me to remember
Robert> having done so. Perhaps seven years ago when I started using
Robert> Python, 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]

Robert> Okay, not often enough or annoyingly enough for me to remember
Robert> having done so. Perhaps seven years ago when I started using
Robert> Python, 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:

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

 

[Steven D'Aprano]

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

Redundancy in *what*?

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

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

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

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

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

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

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

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

 

[Antoon Pardon]

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.

 

[Christophe]

Stephen Eilert a écrit :

Well, I *hate* underscores with a passion. So it is kinda frustrating
that I *have* to say "__init__". The fact that the coding conventions
for Python suggest things such as methods_called_this_or_that do not
help. Everything else seems fine, since if there's voodoo involved, it
had best be sticking out from the text in big, bloody, blinking, red
letters.

I know, there's noone preventing me from doing otherwise (except for
that blasted __init__). I'd like to follow the pack here, tho.

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

 

[Steven D'Aprano]

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

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

I suppose, theoretically, if you could find some cost-free redundancy,
something that just happened for free, we would have no reason to care
whether it existed or not. But since cost-free redundancies don't exist,
or at least are very rare, we should prefer to remove redundancies UNLESS
they offer some advantage.

 

[Antoon Pardon]

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

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

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

 

[Magnus Lycka]

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

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

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

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

 

[Fredrik Lundh]

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

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

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

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

</F>

 

[Steve Holden]

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

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

regards
Steve

 

[Fredrik Lundh]

I'm always surprised by the amount of energy that's put into this type
of discussion - even the OP has suggested that this isn't a big issue.
If it's not a big issue why is this thread still going?

http://www.bikeshed.org/

</F>

 

[Steve Holden]

http://www.bikeshed.org/

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

regards
Steve

 

[Fredrik Lundh]

Steve Holden wrote:

y is this thread still going?

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

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