ternary operator vote

[Gareth McCaughan]

Laura Creighton wrote:

[I said:]
> > Gareth> I strongly agree that something very like approval voting is
> > Gareth> the way to go. However, I think pure approval voting isn't
> > Gareth> quite right here. After all, everyone who's using Python right
> > Gareth> now already regards the language we have as *acceptable*...

[Andrew Koenig:]
> > The term "acceptable" is vague, of course.  What approval voting
> > really asks voters to do is to rank-order the alternatives, draw a
> > line between the alternatives that the voter wants and the ones that
> > the voter doesn't want, and vote for all of the alternatives above
> > that line.
> >
> > As Laura Creighton pointed out, that procedure has the disadvantage
> > that many people will pick "no change" by reflex.
...
>  Thus all the people who draw their line just below 'no change', ie
>  most people, will have just cast a ballot where 'no change' is a winner,
>  and so would the people who vote no change first, and then their 2
>  least hated alternatives (if I had to I could live with this) and
>  then draw the line.  A vote which is A B nochange <line> and
>  B A nochange <line> and nochange A B line _all count the same_.
>
>  I confidently predict that no_change will be above the line in the
>  vast majority of Pythonistas votes.  You have just handed me the
>  election.

That was my point. :-) I remark that my proposed +/=/- scheme doesn't
suffer from this problem. More precisely: it throws away slightly less
information than plain approval voting, and makes it possible not to
suffer from the problem. If Guido decides to conflate the "=" and "+"
votes then we're back with approval voting.

-- 
Gareth McCaughan  Gareth.McCaughan at pobox.com
.sig under construc