Update to PEP308: if-then-else expression
Raymond Hettinger
If the cron job is doing its thing, the results will be visible in
a few hours.
The update reflects updated thinking based on the discussion to-date.
It also summarizes a few posts from comp.lang.python.
Hopefully, it will serve to focus the discussion on the
best of the ideas and arguments presented so far.
* Out of order evaluation is out of favor.
* So are ideas that do not provide for short-circuiting.
* (if <condition>: <expression1> else: <condition2>) is in vogue.
* <condition> ?? <expression1> || <expression2> is a new contender.
* cond(<condition>, <expression1>, <condition2>) is viable if implemented
as a keyword and has short-circuit behavior. Note, the actual word
is still an open question. iif() got shot down quickly.
* Added a summary of a few ideas from the last couple hundred posts
from comp.lang.python.
Raymond Hettinger
Oren Tirosh
> * (if <condition>: <expression1> else: <condition2>) is in vogue.
+1
Pros:
No new keywords
Reuses existing concepts
Verbose and explicit. A little more typing never hurt anyone.
Inside parens ':' has no other meaning.
Inside parens significant whitespace is disabled. Makes it more natural
to format and indent this across multiple lines. Reduces temptation to
squash everything into one line.
Concept extends naturally to try/except and other constructs. Not sure
if that's an advantage or not. Could be a slippery slope...
Idea: should be applicable to [],{}, too. Anywhere tok->level >= 1.
> * <condition> ?? <expression1> || <expression2> is a new contender.
-1
> * cond(<condition>, <expression1>, <condition2>) is viable if implemented
> as a keyword and has short-circuit behavior. Note, the actual word
> is still an open question. iif() got shot down quickly.
-1
Short-circuit behavior seems out-of-place in something that looks like a
function call.
P.S. I am still -0 on the concept as a whole, but if it's done, it should
at least be done right.
Oren
John Roth
"Raymond Hettinger" <pyt...@rcn.com> wrote in message
news:mailman.1044943071...@python.org...
> I updated the PEP for Guido van Rossum.
>
> If the cron job is doing its thing, the results will be visible in
> a few hours.
I see it. Great job!
> The update reflects updated thinking based on the discussion to-date.
> It also summarizes a few posts from comp.lang.python.
> Hopefully, it will serve to focus the discussion on the
> best of the ideas and arguments presented so far.
>
> * Out of order evaluation is out of favor.
>
> * So are ideas that do not provide for short-circuiting.
>
> * (if <condition>: <expression1> else: <condition2>) is in vogue.
>
> * <condition> ?? <expression1> || <expression2> is a new contender.
>
> * cond(<condition>, <expression1>, <condition2>) is viable if
implemented
> as a keyword and has short-circuit behavior. Note, the actual
word
> is still an open question. iif() got shot down quickly.
>
> * Added a summary of a few ideas from the last couple hundred posts
> from comp.lang.python.
I prefer the ternary operator masquerading as a function,
however, the I find the actual proposal acceptable.
Which brings up an interesting idea - could we use acceptability
voting?
John Roth
>
>
> Raymond Hettinger
>
Samuele Pedroni
"Raymond Hettinger" <pyt...@rcn.com> ha scritto nel messaggio
news:mailman.1044943071...@python.org...
> * (if <condition>: <expression1> else: <condition2>) is in vogue.
- 10
Andrew Koenig
John> voting?
Funny -- I suggested the same thing (and explained why at length)
elsewhere in this discussion, before reading this note.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Aahz
John Roth <john...@ameritech.net> wrote:
>
>Which brings up an interesting idea - could we use acceptability
>voting?
If I run the voting, and it's a straight "pick between these
alternatives" vote, I'll probably use Condorcet. OTOH, after taking a
quick look at more web pages, approval voting is easier, so maybe I'll
use that instead. <shrug>
Does anyone have actual experience with both Condorcet and approval
voting? (I'm *not* going to use IRV (aka Australian/Hugo).)
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Register for PyCon now! http://www.python.org/pycon/reg.html
Max M
I do like the ternary operator, but strongly dislikes the above syntax.
Normally an if sentence has the form:
if x==21:
result = x*2
else:
result = 42
But now suddenly the if should act like some kind of function and return
a value?
result = (if x==21: x*2 else: 42)
And what is this with parens that has to be there? This is so
inconsistent with how parens are used normally in Python. Normally they
are only needed for tuples, functions and multiline statements.
Should there really be made an inconsistency like that, for a marginal
featue like this?
One of the great thing about the ternary operator is it's tersenes. That
is completely gone with that syntax.
So I must say that I *strongly* favor:
result = x==21 ?? x*2 || 42
--
hilsen/regards Max M Rasmussen, Denmark
http://www.futureport.dk/
Fremtiden, videnskab, skeptiscisme og transhumanisme
Gerald S. Williams
> I updated the PEP for Guido van Rossum.
Great job! Thanks.
Two things you may consider adding:
(1)
> * (if <condition>: <expression1> else: <condition2>) is in vogue.
There was some discussion about allowing elif: in this context, which
is a natural thing to consider (at least as an option).
(2)
The current alternatives shown in the PEP and in FAQ section 4.16
all have serious drawbacks, as both are quick to point out. A more
workable alternative using existing constructs could be shown. I
propose showing a variant of the Tim Peters alternative (feel free
to rename ifelse() into cond(), iif(), or whatever you please):
def ifelse(x): return [x]
... ifelse(cond and [true-expr] or [false-expr])
Note that this is an n-ary operation:
... ifelse(a and [x] or b and [y] or c and [z] or ...)
I'm not against adding ternary (or n-ary) operations, but existing
alternatives should really be given fair treatment.
-Jerry
Rich Harkins
of any type. Perhaps if I post it to this thread I can get indications
of why this would be a bad idea (some slight revisions have been made
but the idea is the same):
I suggest creating a new singleton called "Default" or some such which
has the following properties:
1) When used as the left-hand side of a logical "and", the right hand
side is not evaluated and the result is Default.
2) Always acts as a false in other boolean operations (such as "or").
3) When used as a function: if the argument passed is non-zero (True)
then return the argument otherwise return the Default object.
4) Overload the keyword "else" (default OR) to act exactly as
traditional "or" except that it will ONLY execute the right hand side if
the left hand side is Default (thus eliminating the false-left-side
case).
For example:
Default(condition) and truecase else falsecase
One could very well alias "Default" as "Test" if 7 letters is too much
typing (i.e.: Test(condition) and truecase else falsecase).
By doing this truecase could produce any value and the falsecase is
never executed. In addition, truecase COULD produce Default indicating
that it the falsecase value is acceptible to the truecase after all. As
an added bonus, the following also makes sense:
x=Default # We don't care
print "x is",x else 5 # 5 because x is Default.
x=0
print "x is now",x else 5 # 0 because x is not Default
Obviously, the spellings would have to change as appropriate but you get
the idea.
To sum up, why couldn't we create an entity such that it yields to any
other entity when manipulated?
Here are the advantages I see to this:
1) No new keywords and only alters the meaning of one keyword.
2) Does not require trinary operation and looks like the classic and-or
pattern.
3) Visible enough to indicate something interesting is happening.
4) Creates a useful new value that can yield to any other value
including false values (unlike None as it stands now).
5) Maintains short-circuiting properties.
Anyway, since I didn't get a response to my previous posting I thought
I'd run it up the flagpole one more time and check to see if anyone even
reading it.
Rich
sism...@hebmex.com
> So I must say that I *strongly* favor:
>
> result = x==21 ?? x*2 || 42
>
That's way ugly, even for C/C++ syntax.
In C, this is perfectly valid:
x = w + s ? a : b + k;
but it's pretty hard to parse on sight, it's
vastly better to write:
x = w + (s ? a : b) + k;
YES, it is a contrived and simpleminded example,
but requiring parenthesis around the conditional
expression (or printing a warning when compiling
one without, warning of possible ambiguities) will
keep python easy on the eyes, and shut up all
detractors which base their arguments on possible
confusion and loss of readability.
-gustavo
Andrew Koenig
Aahz> alternatives" vote, I'll probably use Condorcet. OTOH, after taking a
Aahz> quick look at more web pages, approval voting is easier, so maybe I'll
Aahz> use that instead. <shrug>
By approval voting, I assume you mean allowing people to vote for as
many alternatives as they like. In which case I'm strongly in favor
of the idea; I posted another note in this discussion explaining why.
Aahz> Does anyone have actual experience with both Condorcet and approval
Aahz> voting? (I'm *not* going to use IRV (aka Australian/Hugo).)
Here's a personal experience with approval voting.
During the organizational meeting of the C++ standards committee, in
December 1989, I proposed approval voting to the committee. There was
a lot of discussion while people tried to sort out what it meant. At
the end of that discussion, most people didn't care much but there was
a general trend in favor of it -- except for one person who seemed to
have decided that he would oppose any suggestion I made regardless of
its merits.
Anyway, after much discussion, we voted on the idea of using approval
voting in future multi-way votes and there was a small but comfortable
margin in favor of it. Then we broke for lunch.
I had lunch in a restaurant with surprisingly slow service, on account
of which I returned 20 minutes late to the afternoon session. By that
time, the guy who opposed anything I did had already introduced a motion
to repeal my original proposal, and gotten the committee to accept it.
I never did find out what arguments he used.
Duncan Booth
news:9T82a.76801$Hl6.7...@news010.worldonline.dk:
> And what is this with parens that has to be there? This is so
> inconsistent with how parens are used normally in Python. Normally they
> are only needed for tuples, functions and multiline statements.
Parentheses are not needed for tuples (except the empty tuple).
--
Duncan Booth dun...@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
Aahz
Andrew Koenig <a...@research.att.com> wrote:
>
>Aahz> If I run the voting, and it's a straight "pick between these
>Aahz> alternatives" vote, I'll probably use Condorcet. OTOH, after taking a
>Aahz> quick look at more web pages, approval voting is easier, so maybe I'll
>Aahz> use that instead. <shrug>
>
>By approval voting, I assume you mean allowing people to vote for as
>many alternatives as they like. In which case I'm strongly in favor
>of the idea; I posted another note in this discussion explaining why.
That's almost correct. "Approval voting" as a term applies to a system
where one can vote YES/NO/ABSTAIN on each of several items. Condorcet
is one of a series of ranking systems, where one lists items in the
order in which one prefers them. The problem with all the ranking
systems that I've seen is that there is no way to directly indicate
disapproval. (This is deadly to IRV, but I don't particularly like that
Condorcet doesn't fix that problem. The flip side is that ranking
systems generally do well at finding the result that the fewest people
object to even without NO votes. It is a provable axiom that no voting
system is perfect, BTW.)
>Aahz> Does anyone have actual experience with both Condorcet and approval
>Aahz> voting? (I'm *not* going to use IRV (aka Australian/Hugo).)
>
>Here's a personal experience with approval voting.
That's interesting, but I really am only interested in answers to my
precise question.
Andrew Koenig
Aahz> Andrew Koenig <a...@research.att.com> wrote:
>>
Aahz> If I run the voting, and it's a straight "pick between these
Aahz> alternatives" vote, I'll probably use Condorcet. OTOH, after taking a
Aahz> quick look at more web pages, approval voting is easier, so maybe I'll
Aahz> use that instead. <shrug>
>>
>> By approval voting, I assume you mean allowing people to vote for as
>> many alternatives as they like. In which case I'm strongly in favor
>> of the idea; I posted another note in this discussion explaining why.
Aahz> That's almost correct. "Approval voting" as a term applies to a system
Aahz> where one can vote YES/NO/ABSTAIN on each of several items.
That's not what I see in http://www.electionmethods.org/approved.htm
Could it be that people are using the same term to denote two
different ideas?
Aahz> Condorcet is one of a series of ranking systems, where one
Aahz> lists items in the order in which one prefers them. The problem
Aahz> with all the ranking systems that I've seen is that there is no
Aahz> way to directly indicate disapproval.
Sure there is -- just arrange for "no change" to be one of the
alternatives. If someone votes for "no change" and nothing else,
that directly indicates disapproval.
Michele Simionato
>
> If the cron job is doing its thing, the results will be visible in
> a few hours.
>
> The update reflects updated thinking based on the discussion to-date.
> It also summarizes a few posts from comp.lang.python.
> Hopefully, it will serve to focus the discussion on the
> best of the ideas and arguments presented so far.
>
> * Out of order evaluation is out of favor.
>
> * So are ideas that do not provide for short-circuiting.
>
> * (if <condition>: <expression1> else: <condition2>) is in vogue.
>
> * <condition> ?? <expression1> || <expression2> is a new contender.
somebody proposed
<condition> then <expression1> else <expression2>
which is also viable if "then" is made a pseudo keyword analogous to "as"
Terry Reedy
"Rich Harkins" <ri...@worldsinfinite.com> wrote in message
news:mailman.1044977078...@python.org...
It took me awhile to see that this actually works as desired.
Interesting. I might actually like it better than the if-else
proposal.
Terry J. Reedy
Laura Creighton
> http://mail.python.org/mailman/listinfo/python-list
[cc'd to Dave Brueck, in the hopes that it will be interesting to him]
I've got a fair bit of experience with both of these. (I think I have
spent too much time joining Societies full of people who are _really_
into electoral process). Both of them have a bad problem for our
purposes; they exist to 'determine winners in elections which must
have a winner'. When you add 'or do nothing' to the mix, bad things
happen to your electoral process. So we always pulled them out to
use, after we passed a resolution 'resolved, we are going to do
something rather than nothing'. Since this is the basis of contention
here, I don't see how this is going to help us. I will explain for
Approval voting, because I don't want to explain Concordet to anybody.
You can go look both Approval and Concordet up here:
http://electionmethods.org/index.htm or
http://electionmethods.org/fr/index.htm if you like French better.
<Then you will understand why I don't want to explain Concordet.>
( By the way, there is a Python script that implements the Cloneproof
Condorcet SSD (SchwartzSequential Dropping) algorithm onsite.
http://electionmethods.org/CondorcetSSD.py
authors Mike Ossipoff and Russ Paielli. pleased me. )
I don't see how approval voting is going to help us. I was taught
that you cannot use it when one of the alternatives is 'or do nothing'.
This is because either a) everybody votes for a, b, or nothing; c, d
or nothing; and so on or so forth. There is a built-in bias for
nothing -- it is only up against the people who aren't going to take
no for an answer. Nobody will be happy with this result. The people
who are pro will feel cheated, and rightly so. 'The system was
stacked against us', they will claim.
Conversely, you can forbid those people who vote for any proposal to
also vote for nothing. This too has a bias. The least offensive
proposal of the alternatives gets in, as opposed to nothing, where
offensive is measured by how many people refuse to vote for it at
all. This is how the bland often get elected ... implementing this in
the absense of a strong front runner. But then you _can_ get a
situation where more people would prefer to do nothing than have any
particular candidate, and vastly more people would rather do without
than have this least offensive one. You have just made an unhappy
electorate. Those who were opposed will say 'But more people would
prefer to do nothing that have this rotten thing! The system was
stacked against us! We could have beat any single proposal, but not
_every_ proposal!' And they are quite correct about this. Moreover,
in the 'pro' camp, things are not necessarily very rosy. If the bland
candidate is also popular, then the coalition parties all night, happy
that one of the choices they liked won. But if this truly is a
victory of the least offensive, it is entirely possible to discover
that you have elected a member whom nobody has any enthusiasm for.
Absolutely everybody thinks that the best choice was missed.
Moreover, they think that the best choice was _guaranteed_ to be
missed, because the 'best man for the job' is almost always extremely
unpopular with a minority. 'The system was stacked against us', they
will complain. 'We never wanted the least offensive candidate, we
only wanted the best one.'
This is why, if the pro camp can actually reach consensus, and back
_one_ candidate, things go much better. They can use Approval voting,
or Concordet to do so, because for them, there it no 'or nothing' vote
to consider. They have _got_ to produce a candidate. But this has a
problem as well. If they have an open primary, all the Anti camp can
come over, and make sure that somebody unelectable in the final vote
wins the primary. So you close your primary, and demand strict party
dicipline. 'All party members are required to vote for the candidate
we annoint, holding your nose if necessary'. This stacks the
candidate selection on the part of the party machine, if there is one.
That discipline (and money) is what a party machine can promise, which
is why it prospers. But not having a 'lets add a whole bunch of
features into Python' party, there isn't a lot of opportunity for a
machine to develop around here.
If the pro camp cannot reach consensus, things are not good.
Right now, my sense is that the 'pro ternary conditional party' is
already reaching consensus on what form they should use through
discussion and debate, including debate with those who are out and out
anti. They are going to produce a candidate which all but a few of
them consider the best. They aren't interested in the bland
candidate, they are working hard at the hearts and minds of their own
party trying to get the best they have. This is the best outcome for
all of us. When they are done producing one, we can vote it up or
down. But if they stop cohering, and have a big spatt, then we have
to consider what we want to do. One tradition is to vote both (let us
hope we are stuck with only two) proposals up or down. If they both
manage to carry, you either select the one that carried by the larger
majority, or you stick the leaders of both proposals in a room and say
'Come out with one proposal. We really mean it this time.'
Laura Creighton
Dave Brueck
> > Does anyone have actual experience with both Condorcet and approval
> > voting? (I'm *not* going to use IRV (aka Australian/Hugo).)
>
> I've got a fair bit of experience with both of these. (I think I have
> spent too much time joining Societies full of people who are _really_
> into electoral process).
Thank you, Laura. I appreciate you taking the time to write it all up. As
usual, c.l.py is educational in ways not limited to just Python.
Now we just have to figure out which election method to use to vote for
which election method to use to vote on the PEP and we'll be done! <wink>
-Dave
Raymond Hettinger
> > * (if <condition>: <expression1> else: <condition2>) is in vogue.
[Samuele Pedroni]
> - 10
Wow, that's pretty strong.
To make it stick, it helps to post your reasons.
My own reasons for avoiding this one are:
* you have to look twice to see that you're dealing
with an expression rather than an if-statement
* when looking at an expression, my mind is trained
to see alpha characters as a variable or function name
* the enclosing parenthesis requirement feels wrong
* there is an unpleasant Smalltalk flavor to having
a single, expression operator take two keywords
followed by colons and parameters. There is nothing
else like it in Python (it doesn't fit).
All of these problems are solved by using punctuation
instead of keywords:
c ?? a || b c ? a : b c ? a ! b
Raymond Hettinger
Bengt Richter
[...]
>Aahz> Condorcet is one of a series of ranking systems, where one
>Aahz> lists items in the order in which one prefers them. The problem
>Aahz> with all the ranking systems that I've seen is that there is no
>Aahz> way to directly indicate disapproval.
>
>Sure there is -- just arrange for "no change" to be one of the
>alternatives. If someone votes for "no change" and nothing else,
>that directly indicates disapproval.
Disapproval of which alternative?
I think I'd prefer an explicit [-1][-0][+0][+1] radio button set for
each alternative to be voted upon.
Regards,
Bengt Richter
Evan Simpson
> * you have to look twice to see that you're dealing
> with an expression rather than an if-statement
They behave almost identically. If you confuse them when reading,
what's the harm? If you confuse them when writing, you'll get a
SyntaxError, not a subtle bug.
> * when looking at an expression, my mind is trained
> to see alpha characters as a variable or function name
Including 'and', 'or', 'not', 'lambda', and the various keywords used in
list comprehensions? (Not that I like listcomp syntax). Isn't your
mind trained to see familiar keywords?
> * the enclosing parenthesis requirement feels wrong
They eliminate precedence issues, make distinguishing statement from
expression trivial, and simplify the grammar.
> * there is an unpleasant Smalltalk flavor to having
> a single, expression operator take two keywords
> followed by colons and parameters. There is nothing
> else like it in Python (it doesn't fit).
'lambda' uses a colon, and listcomps use multiple keywords inside
delimiters. Python doesn't have any n-ary operator for n>2, so there
won't be anything like *any* PEP308 syntax, in that sense.
> All of these problems are solved by using punctuation
> instead of keywords:
>
> c ?? a || b c ? a : b c ? a ! b
The folks who object to PEP308 regardless of syntax have a point when
they observe that conditional expressions seem to be very rare in
practice. Given that fact, if Guido agrees to add them to Python, they
ought to be either "intuitive" or very easy to look up.
None of the punctuation forms is easy to look up, and only the one taken
from C is likely to be immediately comprehensible to someone who isn't
familiar with them. If they are chained or used with complex
expressions, you either need to add as many as *three* sets of
parentheses, or hope that the "obvious" precedence works.
The "if C: x else: y" syntax is trivial to teach, read, and remember
*because* it is just like an if-statement in parentheses, with
expressions instead of statement suites.
Cheers,
Evan @ 4-am
Andrew Koenig
>> alternatives. If someone votes for "no change" and nothing else,
>> that directly indicates disapproval.
Bengt> Disapproval of which alternative?
Disapproval of all of the alternatives except "no change".
Delaney, Timothy C (Timothy)
>
> I think I'd prefer an explicit [-1][-0][+0][+1] radio button set for
> each alternative to be voted upon.
Make that [-1][-0][0][+0][+1] to cater for those who have *no* preference at all on a particular item.
Of course, I won't be such a person. So far, I'm:
+0 on having a ternary at all (was -0, but found an option I liked);
-0 on having a short-circuiting ternary - I've yet to find something that *relies* on short-circuiting in a ternary which didn't require me to think hard about what was going on - control flow should be explicit;
-2 on all syntax proposals which are not of the form <test> <true result> <false result>;
+1 on bool.if(self, trueresult, falseresult)
where `if` obviously needs to be replaced with something else e.g.
(x == y).ifelse(True, False)
which of course will not be an option in the voting because it doesn't short-circuit;
-1 on all other current syntax proposals.
Tim Delaney
Andrew Bennetts
>
> +1 on bool.if(self, trueresult, falseresult)
>
> where `if` obviously needs to be replaced with something else e.g.
>
> (x == y).ifelse(True, False)
>
> which of course will not be an option in the voting because it doesn't short-circuit;
This is the first ternary proposal that I actually like rather than actively
dislike.
It's a shame that short-circuiting is considered a requirement; I'm happy
for people to do it the "hard" way in the few cases where it matters, and it
would allow this proposal, which is just a simple method of bools. Very
easy to implement, very easy to explain, and very easy to document (and to
find in the documentation -- just look for ifelse in the index!).
-Andrew.
Scott David Daniels
Delaney, Timothy C (Timothy) wrote:
> ...
> +1 on bool.if(self, trueresult, falseresult)
>
> where `if` obviously needs to be replaced with something else e.g.
> (x == y).ifelse(True, False)
>
> which of course will not be an option in the voting because it
> doesn't short-circuit;
I like the ifelse like this:
print count, 'test%s' % (count > 1).ifelse('s', '')
And for the need to be lazy:
(x > 43).ifelse(lambda:funct(x), lambda:'too many')()
I don't see a problem with asking for lazy where you need it
if we have the way to spell it.
-Scott David Daniels
Scott....@Acm.Org
Terry Reedy
"Evan Simpson" <ev...@4-am.com> wrote in message
news:mailman.104500376...@python.org...
> The folks who object to PEP308 regardless of syntax have a point
when
> they observe that conditional expressions seem to be very rare in
> practice.
I challenge this claim. What means 'very rare'? In the standard
library, and/or conditionals are used at least twice as often as, for
instance list.reverse(). Does that mean that the reverse method is a
mistake? (It is, after all, trivial to write a reverse function or
reversing loop.)
If they really think it will be so very rare, why are they so bent out
of shape at the prospect of having to 'very rarely' read someone usage
thereof?
(The questions are for the objectors, not for you, Evan. But you did
accept their claim as correct.)
Terry J. Reedy
Terry Reedy
"Delaney, Timothy C (Timothy)" <tdel...@avaya.com> wrote in message
+0 on having a ternary at all (was -0, but found an option I liked);
That is not exactly an option. The currently-used ternary,
conditional on the first option being non-null, is "test and opt1 or
opt 2". To me, 100 uses in the standard library makes it
quasi-officially 'blessed'. In any case, it is a straightforward
application of Python's syntax rules. This is the status quo that a
no vote is voting for.
Terry J. Reedy
Andrew Bennetts
>
> I like the ifelse like this:
> print count, 'test%s' % (count > 1).ifelse('s', '')
>
> And for the need to be lazy:
> (x > 43).ifelse(lambda:funct(x), lambda:'too many')()
>
> I don't see a problem with asking for lazy where you need it
> if we have the way to spell it.
Agreed. Hell, you could even do:
if x > 43:
y = funct(x)
else:
y = 'too many'
But that's probably too radical to be accepted <wink>
-Andrew.
Aahz
Terry Reedy <tjr...@udel.edu> wrote:
>
>I challenge this claim. What means 'very rare'? In the standard
>library, and/or conditionals are used at least twice as often as, for
>instance list.reverse(). Does that mean that the reverse method is a
>mistake? (It is, after all, trivial to write a reverse function or
>reversing loop.)
>
>If they really think it will be so very rare, why are they so bent out
>of shape at the prospect of having to 'very rarely' read someone usage
>thereof?
Remember, it's not really *just* frequency, it's frequency times power.
list.reverse() is important solely because it is implemented at the C
level, making it much faster than a version written in Python. More
than that, list.reverse() is obvious (IMO) in meaning in a way that none
of the forms of conditional expressions are: either they use "if" (which
gets confused with the statement form) or they're not directly obvious.
Delaney, Timothy C (Timothy)
Now that's just silly. You knew precisely what I meant.
Tim Delaney
Erik Max Francis
> Andrew Koenig wrote:
>
> > Disapproval of all of the alternatives except "no change".
>
> Which still doesn't handle the case of "I can live with any of
> these EXCEPT x"
Sure it does. Mark every entry except the one(s) you are dead-set
against.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ So look into my eyes / I won't tell you lies
\__/ Neneh Cherry
HardScience.info / http://www.hardscience.info/
The best hard science Web sites that the Web has to offer.
Oren Tirosh
> I don't see how approval voting is going to help us. I was taught
> that you cannot use it when one of the alternatives is 'or do nothing'.
Then separate it into two decisions per voter:
1. Pro/Con any form of if-then-else expression
2. Approval voting of proposed alterntives
This would let me express the opinion that I am against any change, but
if more people are in favor of some kind of in-the-else expression the
form "(if COND: EXPR1 else: EXPR2)" is the one I find most acceptable.
Oren
Erik Max Francis
> This would let me express the opinion that I am against any change,
> but
> if more people are in favor of some kind of in-the-else expression the
> form "(if COND: EXPR1 else: EXPR2)" is the one I find most acceptable.
Approval voting works fine in the case where one of the possible choices
is "do nothing." If you reject the PEP and want to do nothing, you only
mark "do nothing" on your ballot. Problem solved.
In your case, you'd probably want to mark "do nothing" and `if C: x
else: y' (one of the options), and nothing else. That way, you express
that you want no change, but would accept that particular form if it cam
down to it.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I am the essence of overconfidence!
\__/ Capt. Benjamin "Hawkeye" Pierce
Bosskey.net: Counter-Strike / http://www.bosskey.net/cs/
A personal guide to Counter-Strike.
Laura Creighton
No, the 'I would have made them rewrite it' faction gets to vote as
well. That's the 'handing out spraypaint to improve the quality
of vandalism' argument.
Laura
Laura Creighton
>
> > This would let me express the opinion that I am against any change,
> > but
> > if more people are in favor of some kind of in-the-else expression the
> > form "(if COND: EXPR1 else: EXPR2)" is the one I find most acceptable.
>
> Approval voting works fine in the case where one of the possible choices
> is "do nothing." If you reject the PEP and want to do nothing, you only
> mark "do nothing" on your ballot. Problem solved.
>
> In your case, you'd probably want to mark "do nothing" and `if C: x
> else: y' (one of the options), and nothing else. That way, you express
> that you want no change, but would accept that particular form if it cam
> down to it.
Max, are you telling me that if everybody voted 'their favourite,
one other, and do nothing', therefore making 'do nothing' the top
vote getter, you would be pleased with the outcome, and consider it
fair?
Me, I think you have just shot your side in the foot.
Laura
Alex Martelli
> Oren Tirosh wrote:
>
>> This would let me express the opinion that I am against any change,
>> but
>> if more people are in favor of some kind of in-the-else expression the
>> form "(if COND: EXPR1 else: EXPR2)" is the one I find most acceptable.
>
> Approval voting works fine in the case where one of the possible choices
> is "do nothing." If you reject the PEP and want to do nothing, you only
> mark "do nothing" on your ballot. Problem solved.
>
> In your case, you'd probably want to mark "do nothing" and `if C: x
> else: y' (one of the options), and nothing else. That way, you express
> that you want no change, but would accept that particular form if it cam
> down to it.
However, Oren's opinion is different from that of somebody who thinks
"(if C: x else: y) would be WONDERFUL, but if that cannot be, then
``no change'' is better than all other alternatives, which I hate".
Approval voting does not distinguish. _Single transferable vote_
does (see the subthread "STV (was" &c): if the ballot is, say:
[A} no change (no introduction of ternary operator into Python)
[B] (if C: x else: y)
{ etc for C, D, and so on }
Oren might vote "A, B", the other hypothetical somebody would vote
"B, A", and the STV algorithm would distinguish in just the right
way. Say there's only one further choice C, and for example:
40% of voters' preferences are A, B
21% are B, A
20% are A, C
19% are C, A
i.e. 60% of voters prefer no change, though, of those, 2/3 would
rather put up with B than with C (they hate C intensely and B
only a little), 1/3 vice versa; 21% prefer B (but hate C so much
they'd rather see no change than it); 19% prefer C (but hate B
so much they'd rather see no change than it).
Since 60% prefer no change, there should be no change -- and
that is what STV would give.
With approval voting, you'd count 61% for B, 60% for A, 39% for
C -- and would pass B instead. Weird.
I think if you construct all cases in which approval and STV
give different results, STV's outcome is a better match for
the voters' collective preferences.
And don't tell me it's too complicated -- once I'm mailing in
a list of approved alternatives such as "A B", it's just as
simple to take into account that order matters: both "A B"
and "B A" are approval at some level for the two cases, but
"A B" indicates A is preferred, "B A" indicates B is -- quite
natural and simple IMHO.
Alex
Andrew Koenig
Laura> favourite, one other, and do nothing', therefore making 'do
Laura> nothing' the top vote getter, you would be pleased with the
Laura> outcome, and consider it fair?
Laura> Me, I think you have just shot your side in the foot.
Yes, I think you're right. The problem is that when there are
multiple proposals, a lot of people are going to prefer "no change" to
at least some of those proposals, and many of that people may mark "no
change".
On the other hand, unless there is a near-consensus on how to
proceed, perhaps that is the right outcome. That is, after all,
what Guido said he was going to do anyway.
Aahz
Alex Martelli <al...@aleax.it> wrote:
>
>I think if you construct all cases in which approval and STV give
>different results, STV's outcome is a better match for the voters'
>collective preferences.
Not according to http://www.electionmethods.org/
If we're going to go through the rigamarole of STV, we're *definitely*
going for Condorcet, which is provably better than STV.
Note that STV == IRV (Instant Runoff Voting).
Terry Reedy
What I tried to say is "A vote against change is a vote for the status
quo" which hardly seems silly to me at all.
> You knew precisely what I meant.
Given your response, which I have probably also misinterpreted, I
obviously misunderstood you. My apologies.
Terry J. Reedy
Terry Reedy
"Aahz" <aa...@pythoncraft.com> wrote in message
news:b2dr9l$7it$1...@panix2.panix.com...
> In article <lXq2a.171362$0v.47...@news1.tin.it>,
> Alex Martelli <al...@aleax.it> wrote:
> >
> >I think if you construct all cases in which approval and STV give
> >different results, STV's outcome is a better match for the voters'
> >collective preferences.
>
> Not according to http://www.electionmethods.org/
>
> If we're going to go through the rigamarole of STV, we're
*definitely*
> going for Condorcet, which is provably better than STV.
>
> Note that STV == IRV (Instant Runoff Voting).
Here is a 'do both' compromise. List alternatives A, B, C, ... with
'do-nothing' at top or bottom. Voting instruction: list alternatives
in order of preference, and use a vertical bar '|' to separate
acceptable from unacceptable alternatives. Example: CA|BD. Then the
votes could be analyzed both as preference votes and and approval
votes. (Python makes this pretty simple to do 8-). Given that the
vote is advisory, multiple analyses are acceptible, even with varying
results.
Terry J. Reedy
Bengt Richter
>
>"Delaney, Timothy C (Timothy)" <tdel...@avaya.com> wrote in message
>
>+0 on having a ternary at all (was -0, but found an option I liked);
>
>That is not exactly an option. The currently-used ternary,
>conditional on the first option being non-null, is "test and opt1 or
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
My latest idea focuses on fixing this instead of inventing a new ternary.
>opt 2". To me, 100 uses in the standard library makes it
>quasi-officially 'blessed'. In any case, it is a straightforward
>application of Python's syntax rules. This is the status quo that a
>no vote is voting for.
>
The idea works by marking the first option so that it will be treated
as True in logical expression context, but without changing its value. E.g.,
cond and {x} or y
or
cond and {x} or {y}
for the sake of stylistic symmetry, if desired.
Regards,
Bengt Richter
Delaney, Timothy C (Timothy)
>
> Dennis Lee Bieber wrote:
>
> > Andrew Koenig wrote:
> >
> > > Disapproval of all of the alternatives except "no change".
> >
> > Which still doesn't handle the case of "I can live
> with any of
> > these EXCEPT x"
>
> Sure it does. Mark every entry except the one(s) you are dead-set
> against.
Nope. That says "I am in favour of all except x". There is no way to distinguish between
I am in favour.
I could live with it.
I am against it.
Tim Delaney
Bengt Richter
>Dennis Lee Bieber wrote:
>
>> Andrew Koenig wrote:
>>
>> > Disapproval of all of the alternatives except "no change".
>>
>> Which still doesn't handle the case of "I can live with any of
>> these EXCEPT x"
>
>Sure it does. Mark every entry except the one(s) you are dead-set
>against.
>
That's disapproval by dilution. I want concentrated disapproval ;-)
Regards,
Bengt Richter
Erik Max Francis
[restoring attributions ONCE AGAIN]
> Erik Max Francis wrote:
>
> > In your case, you'd probably want to mark "do nothing" and `if C: x
> > else: y' (one of the options), and nothing else. That way, you
> > express
> > that you want no change, but would accept that particular form if it
> > cam
> > down to it.
>
> Max, are you telling me that if everybody voted 'their favourite,
> one other, and do nothing', therefore making 'do nothing' the top
> vote getter, you would be pleased with the outcome, and consider it
> fair?
Since I don't see myself writing that in the above paragraph, I'd have
to say no, I'm not telling you any such thing.
> Me, I think you have just shot your side in the foot.
Reinterpreting my comments in your favor and then condemning me for a
claim I've never made is I believe what's called the "strawman argument
fallacy."
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ You cannot step into the same river once.
\__/ Cratylus
Python chess module / http://www.alcyone.com/pyos/chess/
A chess game adjudicator in Python.
Erik Max Francis
> Here is a 'do both' compromise. List alternatives A, B, C, ... with
> 'do-nothing' at top or bottom. Voting instruction: list alternatives
> in order of preference, and use a vertical bar '|' to separate
> acceptable from unacceptable alternatives. Example: CA|BD. Then the
> votes could be analyzed both as preference votes and and approval
> votes. (Python makes this pretty simple to do 8-). Given that the
> vote is advisory, multiple analyses are acceptible, even with varying
> results.
There's another issue here which nobody has yet addressed. If you're
going to hold a public vote, it should be pretty straightforward to
understand how to do it. If the voting process itself requires five
paragraphs description, I think you're talking about a bad voting
process.
Approval voting has the benefit of being very simple to explain:
"Select as many or as few as you want."
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
Carel Fellinger
> [Raymond Hettinger
> > > * (if <condition>: <expression1> else: <condition2>) is in vogue.
>
> [Samuele Pedroni]
> > - 10
>
> Wow, that's pretty strong.
> To make it stick, it helps to post your reasons.
> My own reasons for avoiding this one are:
why stick with our feelings where the pythonic way is to have
usability studies:) So I wook up my daughters, they know about
HTML and a little javascript and are big fans of Monty Python.
I showed them the following snippets:
1) a = 1
2) if a == 1:
b = 2
else:
b = 3
3) b = 2 if a==1 else 3
4) b = (if a==1: 2 else: 3)
I showed 1) to refresh their knowledge of assignment (years ago I tried
in vein to get them to code using Python). They looked insulted when I
asked them what a was.
Then I showed 2) and asked what b was. Again insulted looks and the right
anwser.
Next I showed 3) and asked for b. As anwser they started to read it
aloud in dutch; realising that it's silly to explain something by
repeating it they got to more verbose reformulations indicating they
understood what was going on.
Next I showed 4) and asked the same....
Bafflement, stupified, it took them ages (okee, seconds) to read it.
Mirte said she doubted she could understand it without having seen 2
and 3. Merel questioned the colons, she expected something that stood
on its own (like a statement) after the collon, not merely a value.
When I later on tried it on my wife (happily computer illiterate, I
had to explain the if statement:), snippet 3 posed no problems, but
again bafflement looking at snippet 4. So much line noise, she
complained, what's with those brackets and those collons, and then
the value for b hidden somewhere in that noise.
All three prefered 2, had no problems understanding 3, but it took
them quit some time to understand 4. Even more remarkably, as they
claimed that having seen snippets 2 and 3 they already knew the anwser.
Not quite what you would have expected, hm. I really hope someone
steps forward and does some usability test before we grow a new wart
on this beautifull language.
...
> All of these problems are solved by using punctuation
> instead of keywords:
>
> c ?? a || b c ? a : b c ? a ! b
I didn't try these yet, will have to wait till tomorrow as the twins
are fast asleep now.
--
groetjes, carel
Manuel Garcia
wrote:
(edit)
>Here is a 'do both' compromise. List alternatives A, B, C, ... with
>'do-nothing' at top or bottom. Voting instruction: list alternatives
>in order of preference, and use a vertical bar '|' to separate
>acceptable from unacceptable alternatives. Example: CA|BD. Then the
>votes could be analyzed both as preference votes and and approval
>votes. (Python makes this pretty simple to do 8-). Given that the
>vote is advisory, multiple analyses are acceptible, even with varying
>results.
This is a great idea!
One problem though, there would be so many ways to "slice-and-dice"
the results, you could prove almost anything. The Pro and Con people
will twist the statistics to show a majority of c.l.p agrees with
them.
But since the one person with the biggest stake in the results is
making the ultimate decision, I can't imagine much controversy with
the decision from people who simply want to be productive in Python.
Manuel
Erik Max Francis
> One problem though, there would be so many ways to "slice-and-dice"
> the results, you could prove almost anything. The Pro and Con people
> will twist the statistics to show a majority of c.l.p agrees with
> them.
This constitutes one of my only reservations about involved voting
procedures: how to reasonably present the results of a vote where
people are really voting yes/no/abstain on n different things at once.
The other concern would be that if the voting process itself is too
complicated (votes must be PGP signed) or is not clear (read these five
paragraphs explaining this voting procedure which you're not familiar
with), then it will drive away potential voters due to simple lack of
convenience, polarizing the results even more.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ If you can't fight and you can't flee, flow.
\__/ Robert Elliot
Physics reference / http://www.alcyone.com/max/reference/physics/
A physics reference.
Bengt Richter
>Terry Reedy wrote:
>
>> Here is a 'do both' compromise. List alternatives A, B, C, ... with
>> 'do-nothing' at top or bottom. Voting instruction: list alternatives
>> in order of preference, and use a vertical bar '|' to separate
>> acceptable from unacceptable alternatives. Example: CA|BD. Then the
>> votes could be analyzed both as preference votes and and approval
>> votes. (Python makes this pretty simple to do 8-). Given that the
>> vote is advisory, multiple analyses are acceptible, even with varying
>> results.
>
>There's another issue here which nobody has yet addressed. If you're
>going to hold a public vote, it should be pretty straightforward to
>understand how to do it. If the voting process itself requires five
>paragraphs description, I think you're talking about a bad voting
>process.
>
>Approval voting has the benefit of being very simple to explain:
>"Select as many or as few as you want."
>
Ok, just let approval values vary from -1 to +1 ;-)
Keep in mind, we are doing this to communicate with the BDFL,
not to present him with a predigested decision run through some
formula. Why not make specific-choice disapproval visible?
Regards,
Bengt Richter
Erik Max Francis
> Ok, just let approval values vary from -1 to +1 ;-)
As someone else pointed out, one problem with this suggestion is that it
seems much more likely to make a typo and write the wrong thing when you
meant something else, whereas it's very hard to mistype YES, NO, or
ABSTAIN (for instance).
> Keep in mind, we are doing this to communicate with the BDFL,
> not to present him with a predigested decision run through some
> formula. Why not make specific-choice disapproval visible?
Yes, but the results are going to have to be digested in some form and
turned into statistical figures that are presented; certainly you
wouldn't buld a huge matrix with voters on one dimension, forms
(including "no change") on the other, populated by floating point values
clamped between -1.0 and +1.0 and hand _that_ over to the BDFL; it needs
to be converted to some kind of statistical result. As such, it _will_
be processed through "some formula[e]." The full results will be
included in the accounting (so that everyone can review them and verify
their authenticity), but presumably the BDFL will judge the decision on
a summarized form of the voluminous data.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Will I disappoint my future / If I stay
\__/ Sade
Bosskey.net: Return to Wolfenstein / http://www.bosskey.net/rtcw/
A personal guide to Return to Castle Wolfenstein.
Tim Peters
That's a wonderful report. Thank you for sharing it (I won't repeat it
here, but everyone do yourself a favor and read it).
> ...
> Not quite what you would have expected, hm. I really hope someone
> steps forward and does some usability test before we grow a new wart
> on this beautifull language.
Guido is sensitive to this kind of stuff <wink -- notoriously sensitive, in
fact>. I hope to see more of it too.
> ...
> Merel questioned the colons, she expected something that stood
> on its own (like a statement) after the collon, not merely a value.
More power to her. The colon doesn't play an essential technical role in
Python's grammar for statements -- the formal grammar almost never needs it.
It's there because usability studies in ABC found that programming newbies
had trouble with indentation alone denoting block structure, but the
troubles went away if the block-opening statement grew a trailing colon.
Carrying that into an embedded expression seems to make some kind of "it's
the same as" sense to Python grownups, but it couldn't be more removed from
the original purpose of the colon. Tell Merel that Uncle Timmy says she's a
very smart person! OTOH, she better not find dict displays confusing too,
or I'll retract that.
> ...
>> All of these problems are solved by using punctuation
>> instead of keywords:
>>
>> c ?? a || b c ? a : b c ? a ! b
> I didn't try these yet, will have to wait till tomorrow as the twins
> are fast asleep now.
If they can make head or tail out of those, trade in your children before
the warranty expires <wink>.
Laura Creighton
I now know that the problem is that you don't understand Approval
Voting. Sorry about that.
Laura
Erik Max Francis
Ah, ad hominem. Congratulations, two logical fallacies in one argument.
Kudos.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Does the true light / Of love come in flashes
\__/ Sandra St. Victor
Lsystem / http://www.alcyone.com/pyos/lsystem/
A Lindenmayer systems explorer in Python.
Laura Creighton
>Laura Creighton wrote:
>
>> Max, I am sorry I characterised you as 'ternary at any price'.
>> I now know that the problem is that you don't understand Approval
>> Voting. Sorry about that.
>
>Ah, ad hominem. Congratulations, two logical fallacies in one argument.
>Kudos.
>
>--
> Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
Aha, so you _do_ understand what will happen in Approval-Voting-A
(where you get to select no change) when 700 people vote for, (for
example), their own if they have it, Bengt Richer's proposal, and no
change, thus demonstrating that there exists no supporter of the
ternary operator who did not also think that Bengt's proposal was
acceptable to them? When I came along, sole supporter of no change,
and cast my single for no change -- no change will win?
And you _do_ understand that in Approval-Voting-B (where anybody
who selects any alternative does not get to vote no change) I could
bring a different electorate, each one this time having written
their own ternary syntax, and have each of them vote only their
own (they won't vote for any others, beause they totally hate
all the other ones that are not their own, and would rather have
no change than those others). Then along comes Alex Martelli, and
he hasn't had time to write his own syntax. So he votes for Bengt's.
Then along comes me. I vote no change. Bengt's now wins.
The logical fallacy of 'ad hominem' is when I say 'Don't vote for
ternaries because Max is an idiot'. I didn't say you were an idiot, I
said that you didn't understand how Approval voting works. And if you
are still for Approval-Voting-A, then I think that you still do not
understand it.
Laura
Erik Max Francis
> The logical fallacy of 'ad hominem' is when I say 'Don't vote for
> ternaries because Max is an idiot'.
"Ad hominem" means "to the person." Ad hominem arguments are those
where you are attacking the person, not what they're saying. I don't
know where you come from, but claiming that someone is wrong because
they're ignorant certainly comes close. That you took the opportunity
to engage in an ad hominem by admitting that you were engaging in a
mischaracterization earlier doesn't exactly pretty the picture.
> And if you
> are still for Approval-Voting-A, then I think that you still do not
> understand it.
Okay, now you've defaulted to, "If you do not agree with me, then you
are ignorant." That sounds like an appeal to authority to me; that
would make a third fallacy. Congratulations, you must have gone for the
three-for-one deal.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ In time of war the devil makes more room in hell.
\__/ (a German proverb)
Crank Dot Net / http://www.crank.net/
Cranks, crackpots, kooks, & loons on the Net.
Anders J. Munch
>
> 1) a = 1
>
> 2) if a == 1:
> b = 2
> else:
> b = 3
>
> 3) b = 2 if a==1 else 3
>
> 4) b = (if a==1: 2 else: 3)
>
> All three prefered 2, had no problems understanding 3, but it took
> them quit some time to understand 4. Even more remarkably, as they
> claimed that having seen snippets 2 and 3 they already knew the anwser.
>
>
> Not quite what you would have expected, hm.
No? (2) is preferred because GvR did a good job designing Python.
(3) is understood through familiarity with language. It reads like a
natural language sentence, which is nice but won't scale to more
complex expressions. (4) is intended to be understood through
familiarity with Python, however your test subjects are very little
familiar with Python.
I wonder how they would resolve the ambiguity in
a = 5
b = a + 1 if a==1 else 3
I'd expect that, reading it as a statement in natural language, they
would come up with b==3 and the possibility of a different
interpretation where b==8 would not even cross their minds.
- Anders
Anna
> Laura Creighton wrote:
>
>> The logical fallacy of 'ad hominem' is when I say 'Don't vote for
>> ternaries because Max is an idiot'.
>
> "Ad hominem" means "to the person." Ad hominem arguments are those
> where you are attacking the person, not what they're saying.
Um, close...
"An Ad Hominem is a general category of fallacies in which a claim or
argument is rejected on the basis of some irrelevant fact about the author
of or the person presenting the claim or argument."
http://www.nizkor.org/features/fallacies/ad-hominem.html
She didn't reject your argument because you're an idiot (or any other
"personal" fact about you)... therefore, it's not an ad hominem.
> I don't know where
> you come from, but claiming that someone is wrong because they're
> ignorant certainly comes close.
Erm, well, yes - but she didn't do that (she clearly gave it as just an
example when you brought up ad hominem). So now you're setting up a
strawman. Nice job.
> That you took the opportunity to engage in an ad hominem by admitting
> that you were engaging in a mischaracterization earlier doesn't exactly
> pretty the picture.
What part of "I don't think you understand this" is an ad hominem? No,
really - I'd like to know. Cuz I'm still waiting for you to address *her*
arguments on Approval-Voting-A and Approval-Voting-B...which, given the
traffic, I may have missed... Feel free to point out where I missed it.
>> And if you
>> are still for Approval-Voting-A, then I think that you still do not
>> understand it.
>
> Okay, now you've defaulted to, "If you do not agree with me, then you
> are ignorant."
Um - no...
Laura explained why she thinks Option A doesn't achieve your expressed
goal. You haven't explained why she's wrong. You seem to be still
supporting it, so: it looks like you don't understand (either Option A or
her argument).
Instead of trying to play logic games, why don't you address her arguments
against Approval voting.
> That sounds like an appeal to authority to me; that would make a third
> fallacy. Congratulations, you must have gone for the three-for-one
> deal.
Congratulations - you've managed to side-step her argument very nicely.
Now, kindly let the rest of us in on why she's wrong please?
Just my $.03 worth.
Anna
--
By caffeine alone I set my mind in motion. By the beans of java the
thoughts acquire speed, the hands acquire shaking, the shaking becomes a
warning. By caffeine alone I set my mind in motion.
Michele Simionato
<snip>
I have just tested my girlfriend, showing her the examples provided by Carel.
The result are the following:
1) a=1
Of course, it means that a is equal to 1, I understand that!
2) if a == 1:
b = 2
else:
b = 3
There are two mistakes: == should be = and the colons after else are wrong.
This statement means that if a=1 then b can be 2 or 3.
3) b = 2 if a==1 else 3
A perverse form of writing 2). Still the == is wrong.
4) b = (if a==1: 2 else: 3)
Let me check my e-mail first ...
I had a big trouble explaing to her that b cannot be 2 or 3, it is 2 if a=1
and it is 3 otherwise. She said the else was confusing and the colons too.
My girlfriend is a french teacher, she also speaks italians, english, spanish,
a little rumenian, portuguese and some words of russian. She insists that the
current Python usage of colons is wrong and confusing!
It was impossible to convince her that 4) was reasonable...
I must admit that my faith that Python is a big language for beginners has been
shaken :-(
Michele
Damien Morton
are familiar with Javascript.
1) a=1
designer 1+2: ok
2)
if a == 1:
b = 2
else:
b = 3
designer 1+2: ok
3)
b = 2 if a==1 else 3
designer 1: it seems like if you say it out loud it doesn't make sense
[reading it out loud using 'otherwise' instead of 'else' made more
sense]
designer 2: b = 2 (if a == 1) else b = 3...
[not sure what the designer was trying to express by rewriting the
expression]
4)
b = (if a==1: 2 else: 3)
designer 1: a little convoluted too, but there's something about the
colons that makes sense to me
designer 2: seems clear
5)
b = (a == 1? 2, 3)
designer 1: the most clear, but probably just because i know javascript
designer 2: this is cleaner and easier to spot when scanning code...
There are 5 widely known and taught languages I know of that use the C
ternary operator form:
C, C++, Java, C#, Javascript
I would hazard a guess that just about any programmer who has learned a
programming language before coming to Python will have learned one of those
5 languages. I would also hazard a guess that anyone who learns Python as
their first programming language will likely also learn one of the 5 above
mentioned languages later in life.
Erik Max Francis
> Congratulations - you've managed to side-step her argument very
> nicely.
Indeed I have. I have no intention on carrying on a "debate" with
someone who merely intends to invoke logical fallacies to win at any
cost.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Sentimentality is a superstructure covering brutality.
\__/ C.G. Jung
Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
An Esperanto reference for English speakers.
Peter Hansen
>
> More power to her. The colon doesn't play an essential technical role in
> Python's grammar for statements -- the formal grammar almost never needs it.
> It's there because usability studies in ABC found that programming newbies
> had trouble with indentation alone denoting block structure, but the
> troubles went away if the block-opening statement grew a trailing colon.
> Carrying that into an embedded expression seems to make some kind of "it's
> the same as" sense to Python grownups, but it couldn't be more removed from
> the original purpose of the colon.
I have access to an innocent (as in largely unexposed to the discussion
about PEP308 and its alternative) group of Python programmers at work,
specifically eight of them. They have a wide variety of backgrounds,
most with some C, all but one with at least two languages other than
Python.
I'm willing to conduct more "experiments on <shudder> people" if it
will help the cause... but I don't have the time, willingness, or
perhaps even competence to craft a decent study myself.
Proposals are welcome, online or off. If I see one that appears
well-enough conceived to make it worth the effort, I'll put my
vict^H^H^H^H employees to the test and report the results here.
-Peter
Gareth McCaughan
> why stick with our feelings where the pythonic way is to have
> usability studies:) So I wook up my daughters, they know about
> HTML and a little javascript and are big fans of Monty Python.
>
> I showed them the following snippets:
>
> 1) a = 1
>
> 2) if a == 1:
> b = 2
> else:
> b = 3
>
> 3) b = 2 if a==1 else 3
>
> 4) b = (if a==1: 2 else: 3)
[etc]
Try 'em on
b = (if a == 1 then 2 else 3)
and see whether that's any less weird to them than #4.
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Erik Max Francis
> I have access to an innocent (as in largely unexposed to the
> discussion
> about PEP308 and its alternative) group of Python programmers at work,
> specifically eight of them. They have a wide variety of backgrounds,
> most with some C, all but one with at least two languages other than
> Python.
I don't really know how much weight should be afforded to a straw poll
involving only eight people, but if people feel it would be instructive,
go for it.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ It is human nature to think wisely and act foolishly.
\__/ Anatole France
PyUID / http://www.alcyone.com/pyos/uid/
A module for generating "unique" IDs in Python.
Peter Hansen
>
> Peter Hansen wrote:
>
> > I have access to an innocent (as in largely unexposed to the
> > discussion
> > about PEP308 and its alternative) group of Python programmers at work,
> > specifically eight of them. They have a wide variety of backgrounds,
> > most with some C, all but one with at least two languages other than
> > Python.
>
> I don't really know how much weight should be afforded to a straw poll
> involving only eight people, but if people feel it would be instructive,
> go for it.
Perhaps we understand the term "straw poll" differently, but that
wasn't what I intended. dict.org defines that as "an unofficial
vote taken to determine opinion on some issue". I was suggesting
something that involved neither votes nor opinions. I had hoped
the term "study" would suggest that more strongly.
I agree the results might not carry much weight, but on the other
hand I've found Carel's comments somewhat more helpful in certain
respects than two hundred other messages I've read which had lots of
opinion but little or no attempt at objective study.
-Peter
Paul Rubin
> [Carel Fellinger, experiments on <shudder> people]
>
> That's a wonderful report. Thank you for sharing it (I won't repeat it
> here, but everyone do yourself a favor and read it).
I have to say that while I admire the spirit, these "usability
studies" involving non-Python programmers seem a little bit silly.
Lots of the other stuff that's basic to Python, like the "self"
argument to class methods, the __init__ method, the ''.join(x) idiom,
the range function (i.e. using "for i in range(1,11)" instead of
"for i = 1 to 10"), are all at least as non-obvious in their meaning
as most of the PEP 308 candidates we've discussed.
I'm also unconcerned that non-programmers (I mean complete
non-programmers, not just non-Python programmers) will have more to
get confused by when reading Python code, if there's another simple
construct in the language. The problems they'll face will have more
to do with understanding the algorithms, function calls,
object-oriented methodology, etc. No one who can understand classes
and simple inheritance (to say nothing of REALLY confusing stuff like
metaclasses) is going to have trouble understanding a conditional
expression.
Nor do I believe that keeping Python's syntax and keywords to a bare
minimum really makes Python easier to learn, where "learn" means
"acquire the ability to read and understand a nontrivial Python
program written by somebody else". Minimalizing the language makes
more sense if Python is merely a "glue" language in which nontrivial
programs simply aren't written. But these days, Python is used for
substantial applications. Anyone trying to read one of them really
has to understand the more commonly used functions in the sys, os, and
regexp modules, maybe the math library, perhaps the socket libraries
or urllib or the cgi module or whatever else, depending on what the
application does. And offering a wide selection of library modules is
an explicitly embraced feature ("batteries included") of Python's
philosophy. It seems perfectly consistent to treat built-in features
the same way. Of course the features should be designed cleanly,
just like library modules should be designed cleanly.
So I just don't see any reason to get uppity about fending off
language features that are present in so many other languages without
drawing complaints. That includes not only conditional expressions,
but also case statements, repeat/until loops, etc. Python seems
to be acquiring such features one by one (operators like += appeared
only recently) -- why not just realize that including them is logical,
and not make such a fuss?
Bengt Richter
[...]
>
>So I just don't see any reason to get uppity about fending off
>language features that are present in so many other languages without
>drawing complaints. That includes not only conditional expressions,
>but also case statements, repeat/until loops, etc. Python seems
>to be acquiring such features one by one (operators like += appeared
>only recently) -- why not just realize that including them is logical,
>and not make such a fuss?
c?x:y
is so cryptic, whereas three well-chosen keywords could make the
expression so much more obvious in its meaning, e.g.,
evaluateTheBoolValueOf c thenIfItIsTrueGetThisExpressionValueByEvaluating x otherwiseGetThisExpressionValueByEvaluating y
of course you may want to take advantage of newline freedom within parens:
(evaluateTheBoolValueOf c
thenIfItIsTrueGetTheValueOfThisExpressionByEvaluating x
otherwiseGetTheValueOfThisExpressionByEvaluating y)
;-)
Regards,
Bengt Richter