PEP 308: Alternative conditional operator forms
Erik Max Francis
conditional operator that have been made so far that people have thought
had _some_ merit (i.e., ones that were proposed and which someone other
than the proponent indicated they thought might be a good idea), and
those which Guido has not already absolutely dismissed (such as C ? x :
y). I'd like to do this both for my own edification in seeing them all
in one place and for a potential second vote on the desired form (should
the process get that far, of course). (I'm also putting aside for the
moment the issue of the introduction of new keywords or punctuation, or
the appearance of chained conditional operators.)
Note this is not a vote of any kind; the forms are listed in the very
rough chronological order of them being suggested, with no other implied
weighting on their position in the list.
Here is the list I have so far (C represents the conditional expression,
x the if-true expression, y the if-false one):
x if C else y # initial proposition in PEP
C ? x ! y # mentioned in PEP
(if C then x else y) # mentioned in PEP
x when C else y
(if C: x else: y)
C ? x else y
C -> x else y
C -> (x, y)
What else should be on this list? (You can reply by email if you wish.)
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Light ... more light!
\__/ (the last words of Goethe)
Bosskey.net / http://www.bosskey.net/
A personal guide to online multiplayer first person shooters.
Paul Rubin
> Here is the list I have so far (C represents the conditional expression,
> x the if-true expression, y the if-false one):
>
> x if C else y # initial proposition in PEP
> C ? x ! y # mentioned in PEP
> (if C then x else y) # mentioned in PEP
> x when C else y
> (if C: x else: y)
> C ? x else y
> C -> x else y
> C -> (x, y)
>
> What else should be on this list? (You can reply by email if you wish.)
cond(C, :x, :y) and some variants on this which I don't remember exactly
Numerous other deferred evaluation schemes
A few macro schemes from threads gone by
Erik Max Francis
> cond(C, :x, :y) and some variants on this which I don't remember
> exactly
The cond(C, :x, :y) was just a builtin function cond using a new
introduced syntax for "thunks" (zero-argument lambdas; :x would be short
for lambda: x), so I don't think that really qualifies as a conditional
operator a la PEP 308; it's a short-hand for lambdas and a function
which uses them in a certain way, rather than a conditional operator
(the conditional operator suggested above would be just one application
of it).
Paul Paterson
news:3E46F0CE...@alcyone.com...
> I'd like to build an exhaustive (or nearly so) of forms of the
> conditional operator that have been made so far that people have thought
> had _some_ merit (i.e., ones that were proposed and which someone other
> than the proponent indicated they thought might be a good idea), and
> those which Guido has not already absolutely dismissed (such as C ? x :
> y). I'd like to do this both for my own edification in seeing them all
> in one place and for a potential second vote on the desired form (should
> the process get that far, of course). (I'm also putting aside for the
> moment the issue of the introduction of new keywords or punctuation, or
> the appearance of chained conditional operators.)
>
> Note this is not a vote of any kind; the forms are listed in the very
> rough chronological order of them being suggested, with no other implied
> weighting on their position in the list.
>
> Here is the list I have so far (C represents the conditional expression,
> x the if-true expression, y the if-false one):
>
> x if C else y # initial proposition in PEP
> C ? x ! y # mentioned in PEP
> (if C then x else y) # mentioned in PEP
> x when C else y
> (if C: x else: y)
> C ? x else y
> C -> x else y
> C -> (x, y)
>
> What else should be on this list? (You can reply by email if you wish.)
y or x if C # as in, val = sqrt(x) or "imag" if x<0
Paul Rubin
> > exactly
>
> The cond(C, :x, :y) was just a builtin function cond using a new
> introduced syntax for "thunks" (zero-argument lambdas; :x would be short
> for lambda: x), so I don't think that really qualifies as a conditional
> operator a la PEP 308; it's a short-hand for lambdas and a function
> which uses them in a certain way, rather than a conditional operator
> (the conditional operator suggested above would be just one application
> of it).
I'd include it on the alternatives list anyway, along with macro
schemes, and anything else that accomplishes the functionality.
PEP 308 is motivated by the frequently asked question of "how do I do
something like ?:" and the recognition that the answers that result
are unsatisfactory to a lot of us. If there were a built-in
conditional function like the above, I think I would find that answer
satisfactory, especially if I thought the implementation wasn't
penalizing me too much for using it.
So I think a reasonable criterion for including something on your
alternatives list is: include it if you think it would make a
satisfactory answer to "how do I... ".
Erik Max Francis
> I'd include it on the alternatives list anyway, along with macro
> schemes, and anything else that accomplishes the functionality.
Quite so. So far I'm keeping three lists: 1. suggestions that there
was some independent affirmative support for (which includes the three
forms mentioned in the PEP), 2. suggestions that I didn't see any
affirmative support for, and 3. more general solutions that would only
degenerate to the effects of a conditional operator in a special case.
Sean Ross
>
> What else should be on this list? (You can reply by email if you wish.)
>
[x if C else y]
(proposed by Alex Martelli, in a previous post)
David Gausebeck
>x the if-true expression, y the if-false one):
>
>x if C else y # initial proposition in PEP
>C ? x ! y # mentioned in PEP
>(if C then x else y) # mentioned in PEP
>x when C else y
>(if C: x else: y)
>C ? x else y
>C -> x else y
>C -> (x, y)
>
>What else should be on this list? (You can reply by email if you wish.)
Paul Rubin suggested
<new keyword> C: x else y
and I like it, but no one else seems to have commented either way.
The original suggestion was for a keyword of 'ifelse' or possibly
'select'. I would prefer 'when' or 'case':
ifelse C: x else y
when C: x else y
case C: x else y
-Dave
Erik Max Francis
> I'd prefer to avoid overloading the : (which currently tends
> to not
> only end a type of statement, but /also/ signals the expected start of
> a code block -- even though a one-statement code block /can/ be put on
> the same line).
Lambdas are an obvious exception to this.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ She glanced at her watch ... It was 9:23.
\__/ James Clavell
Bosskey.net: Quake III Arena / http://www.bosskey.net/q3a/
A personal guide to Quake III Arena.
David Gausebeck
>>
>> and I like it, but no one else seems to have commented either way.
>> The original suggestion was for a keyword of 'ifelse' or possibly
>> 'select'. I would prefer 'when' or 'case':
>>
>> ifelse C: x else y
>> when C: x else y
>> case C: x else y
>>
>only end a type of statement, but /also/ signals the expected start of
>a code block -- even though a one-statement code block /can/ be put on
The reason the : makes sense for me is that the syntax here is
essentially the same as for 'if', except that this is an expression.
To make it even more analogous, it could be
ifelse C: x else: y
which, now that I look at it again, is what Paul Rubin actually
suggested. I guess I dropped the second : because it's unnecessary.
But you do need something between C and x.
> Assuming the creation of new keywords should be allowed...
>
> when C then x otherwise y
>
>which may even allow for a form of multiple choice nesting...
>
> when C1 then x when C2 then y ... otherwise z
>
>wherein the "otherwise" becomes the expression if none of the
>"when/then" sets is taken.
Why add a new keyword ('otherwise') when an existing one fits
perfectly and causes no conflicts? 'else' in this context seems like
a no-brainer.
As for chaining, that could work in a couple ways depending on the
choice of keyword. With ifelse, elif is the obvious choice:
ifelse C1: x elif C2: y else z
With case, you just continue to use case:
case C1: x case C2: y else z
Of course, whether chained conditionals are even desirable is a
subject of debate. They can always be implemented via nesting,
however, and I'd say that
case C1: x case C2: y else z
is slightly clearer than
case C1: x else (case C2: y else z)
-Dave
Erik Max Francis
> The reason the : makes sense for me is that the syntax here is
> essentially the same as for 'if', except that this is an expression.
> To make it even more analogous, it could be
>
> ifelse C: x else: y
...
> Why add a new keyword ('otherwise') when an existing one fits
> perfectly and causes no conflicts? 'else' in this context seems like
> a no-brainer.
I'm going to turn that one right around on you. Why add the new keyword
`ifelse'? Why not use `if'?
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
David Gausebeck
>> essentially the same as for 'if', except that this is an expression.
>> To make it even more analogous, it could be
>>
>> ifelse C: x else: y
> ...
>> Why add a new keyword ('otherwise') when an existing one fits
>> perfectly and causes no conflicts? 'else' in this context seems like
>> a no-brainer.
>
>I'm going to turn that one right around on you. Why add the new keyword
>`ifelse'? Why not use `if'?
Yes, that's the obvious responding question :) Which is why I worded
my statement as I did. The problem with using 'if' here is that it
conflicts with the current use of the keyword 'if'.
Or at least I believe that's the case... there's some discussion going
on about that right now in the main PEP thread. If it turns out that
the interpreter can nicely support
lval = if C: x else: y
then I'd be perfectly happy with it. My support for an alternate
keyword is based on the assumption that the above syntax can't work.
hmm... looking at that, it seems that the interpreter would have
enough context by the time it gets to the 'if' to know if it needs to
be an expression or not. If the 'if' is an rvalue (function arg, list
element, etc.) then it's an if-expression, otherwise it's a normal
'if'.
-Dave
Christos TZOTZIOY
<m...@alcyone.com> might have written:
>Here is the list I have so far (C represents the conditional expression,
>x the if-true expression, y the if-false one):
>
>x if C else y # initial proposition in PEP
>C ? x ! y # mentioned in PEP
>(if C then x else y) # mentioned in PEP
>x when C else y
>(if C: x else: y)
>C ? x else y
>C -> x else y
>C -> (x, y)
>
>What else should be on this list? (You can reply by email if you wish.)
C then x else y
--
TZOTZIOY, I speak England very best,
Real email address: 'dHpvdEBzaWwtdGVjLmdy\n'.decode('base64')
Erik Max Francis
> Or at least I believe that's the case... there's some discussion going
> on about that right now in the main PEP thread. If it turns out that
> the interpreter can nicely support
>
> lval = if C: x else: y
>
> then I'd be perfectly happy with it. My support for an alternate
> keyword is based on the assumption that the above syntax can't work.
I don't see why it can't. As far as I can tell (someone please correct
me if this is wrong), the `if' that starts an if statement can always be
distinguished from the `if' that starts the conditional operator except
in one case (The Corner Case), where a conditional operator is a
solitary expression as a lone statement. That case doesn't interest me,
so it would be perfectly satisfactory to me for Python to interpret that
as an error, since it's better written as an actual if statement anyway.
(Parenthesize it or transform it to a real, live if statement; your
choice.)
I can't see any other conflicts than that, because in a script when the
parser is doing its thing, it knows whether it's expecting a statement
or an expression.
The only other case I can think of, which someone offhandedly alluded to
but didn't go into depth, would be the "single" compilation, as the
interactive interpreter does, where it will take a string and interpret
it either as an expression or a statement depending on which it is. In
this case it would be perfectly satisfactory to me for it to default to
the if statement, not the conditional operator. It's just a matter of
choosing which you'd prefer. I just see that as really another example
of the Corner Case; it's a who-cares-as-long-as-it's-consistent
proposition.
> hmm... looking at that, it seems that the interpreter would have
> enough context by the time it gets to the 'if' to know if it needs to
> be an expression or not. If the 'if' is an rvalue (function arg, list
> element, etc.) then it's an if-expression, otherwise it's a normal
> 'if'.
Right. If the `if' is the first keyword in a statement or single, then
it's the if statement. If it's the first keyword in an expression, then
it's the conditional operator. I see no conflicts.
Again, please someone correct me if I'm wrong here.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ No man quite believes in any other man.
\__/ H.L. Mencken
Alcyone Systems / http://www.alcyone.com/
Alcyone Systems, San Jose, California.
Andrew Dalke
> PEP 308 is motivated by the frequently asked question of "how do I do
> something like ?:" and the recognition that the answers that result
> are unsatisfactory to a lot of us.
But add the condition that "usually when asked it turns out the person
who asked the question didn't realize there was another, better answer
which was available in Python without using the ternary if/else expression"
I gave as some examples
x if x < y else y
when
min(x,y)
is available, or
hex_c = chr(48 + i if i < 10 else 55 + i)
when
hex_c = "0123456789ABCDEF"[i]
and
hex_c = ("%x" % i)[2:]
both exist.
Therefore this proposal must take into account that people will
use it incorrectly (based, eg, on experiences in other langauges)
to the overall detriment of the program.
Andrew
da...@dalkescientific.com
John Roth
"Paul Rubin" <phr-n...@NOSPAMnightsong.com> wrote in message
news:7xel6hr...@ruckus.brouhaha.com...
I thoroughly agree. If I had to choose between deferred evaluation and
any
of the conditional expressions, I'd go with the functional version in a
flash.
I consider it so much clearer that there's simply no comparison.
> A few macro schemes from threads gone by
Well, if you're trying to be completist, but any kind of macro scheme
gets my thumbs down.
John Roth
John Roth
> David Gausebeck wrote:
>
> > The reason the : makes sense for me is that the syntax here is
> > essentially the same as for 'if', except that this is an expression.
> > To make it even more analogous, it could be
> >
> > ifelse C: x else: y
> ...
> > Why add a new keyword ('otherwise') when an existing one fits
> > perfectly and causes no conflicts? 'else' in this context seems
like
> > a no-brainer.
>
> I'm going to turn that one right around on you. Why add the new
keyword
> `ifelse'? Why not use `if'?
Because you've got a major ambiguity if the statement begins
with an "if". That comment is in the PEP.
John Roth
Andrew Koenig
David> lval = if C: x else: y
David> then I'd be perfectly happy with it. My support for an
David> alternate keyword is based on the assumption that the above
David> syntax can't work.
Please see my proposed grammar changes elsewhere in this discussion.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Jeremy Fincher
> PEP 308 is motivated by the frequently asked question of "how do I do
> something like ?:" and the recognition that the answers that result
> are unsatisfactory to a lot of us.
"You don't" wasn't satisfactory? It always worked for me :)
Jeremy
Aahz
Erik Max Francis <m...@alcyone.com> wrote:
>
>What else should be on this list? (You can reply by email if you wish.)
iif(C, x, y)
No, that's not a short-circuiting form.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Register for PyCon now! http://www.python.org/pycon/reg.html
Michele Simionato
> I'd like to build an exhaustive (or nearly so) of forms of the
> conditional operator that have been made so far that people have thought
> had _some_ merit (i.e., ones that were proposed and which someone other
> than the proponent indicated they thought might be a good idea), and
> those which Guido has not already absolutely dismissed (such as C ? x :
> y). I'd like to do this both for my own edification in seeing them all
> in one place and for a potential second vote on the desired form (should
> the process get that far, of course). (I'm also putting aside for the
> moment the issue of the introduction of new keywords or punctuation, or
> the appearance of chained conditional operators.)
>
Erik, thanks for offering your time to prepare the list. However, I think we
should first make sure that there is a majority of Pythonistas favorable to
the introduction of the ternary operator. There is no point in arguing
between us about the more pythonic solution if 80% of users are already
against the ternary operator. I think there is a big majority not
posting on c.l.p that could be contrary to the innovation and don't
bother to sent verbose postings. I fear this majority could kill
us at the voting moment (and maybe Guido counts on that).
First, I would like to see how many are favorable (or not absolutely
contrary) and then I will vote for the choice of the proposal.
Cheers,
Michele
holger krekel
> In article <3E46F0CE...@alcyone.com>,
> Erik Max Francis <m...@alcyone.com> wrote:
> >
> >What else should be on this list? (You can reply by email if you wish.)
>
> iif(C, x, y)
>
> No, that's not a short-circuiting form.
which is rarely needed. Tim Peters <wink> said that with the hundred
cases of the beloved "x and y or z" idiom in the 150+ modules of
Python it's needed exactly 0 (zero) times.
If nobody comes up with sane *real world* use cases for the
short-circuiting behaviour then we should call YAGNI
and not change any syntax. A C-implemented builtin
isn't really that bad.
leaning-towards-a-builtin-ly y'rs,
holger
Tim Peters
>> No, that's not a short-circuiting form.
> which is rarely needed. Tim Peters <wink> said that with the hundred
> cases of the beloved "x and y or z" idiom in the 150+ modules of
> Python it's needed exactly 0 (zero) times.
Nope. I said the relative handful of examples I included didn't need
short-circuiting, and that it was rarely needed. In some cases it is, like
SuiteInfoBase.__init__(self, tree and tree[-1] or None)
but I didn't happen to post that one. Another is
iptfile = args and args[0] or "Python/graminit.c"
In other cases it can be merely more efficient to short-circuit, like
x[1][0] and '" "'.join(x[1]) or ''
The unadorned and/or idiom does short-circuit, so none of the above can be
an issue for it.
What I found much less use for (none in the std library, whether posted or
not) was cause to get excited about the "but if the middle expression is
false and the condition is true, the last expression gets evaluated anyway"
insecurity. Most uses were slinging literal strings and module constants,
where "but that can't happen" was obvious, and the idea that the middle
expression "might be false" ignores that, e.g., no, the literal "yes" is not
false.
In the end, I didn't find any code in the std library I'd change if the PEP
were to be accepted. I didn't study every line, though.
Peter Hansen
>
> Erik Max Francis <m...@alcyone.com> wrote in message news:<3E46F0CE...@alcyone.com>...
> > I'd like to build an exhaustive (or nearly so) of forms of the
> > conditional operator that have been made so far that people have thought
> > had _some_ merit (i.e., ones that were proposed and which someone other
> > than the proponent indicated they thought might be a good idea), and
> > those which Guido has not already absolutely dismissed (such as C ? x :
> > y). I'd like to do this both for my own edification in seeing them all
> > in one place and for a potential second vote on the desired form (should
> > the process get that far, of course). (I'm also putting aside for the
> > moment the issue of the introduction of new keywords or punctuation, or
> > the appearance of chained conditional operators.)
> >
>
> Erik, thanks for offering your time to prepare the list. However, I think we
> should first make sure that there is a majority of Pythonistas favorable to
> the introduction of the ternary operator. There is no point in arguing
> between us about the more pythonic solution if 80% of users are already
> against the ternary operator.
I would think you could consider Erik's efforts to be focusing on
the secondary question of "how to do it", just for that potential
20% (which is likely larger, but that's another story) who do want
the ternary operator.
Don't stop someone who already knows he wants it from putting
together a list that will help likeminded people agree on the
preferred syntax for that operator.
> I think there is a big majority not
> posting on c.l.p that could be contrary to the innovation and don't
> bother to sent verbose postings. I fear this majority could kill
> us at the voting moment (and maybe Guido counts on that).
"counts on that"? That ascribes a somewhat underhanded approach
to this whole thing to someone who appeared to be very open and
upfront about the whole issue. Or am I misinterpreting your comment?
I don't understand all the comments about who can be trusted
to manage the voting, who has ulterior motives, etc... this
isn't *that* big a deal, is it? This is the discussion phase,
where people's opinions can be swayed (even repeatedly :-) and
some of the sillier arguments can be eliminated. After the
dust settles, either a consensus emerges, or the need to
vote is clear and we can proceed to that step. It doesn't
really seem we're there yet, to me.
-Peter
Samuele Pedroni
"Tim Peters" <tim...@comcast.net> ha scritto nel messaggio
news:mailman.1044899301...@python.org...
>
> In the end, I didn't find any code in the std library I'd change if the
PEP
> were to be accepted. I didn't study every line, though.
>
but I think ideally Andrew Koenig would want them changed for pedagogical
reasons.
OTOH personally I think I would still use _ and _ or _ were it works, if the
PEP got approved but the chosen variant is less readable, than what is
basically an idiomatic form to take as such.
Furhter people ideally should still learn how and/or works, if we want them
to write:
if obj and obj.isempty():
...
instead of some if (if ...) variant.
.
holger krekel
> [holger krekel]
> >> No, that's not a short-circuiting form.
>
> > which is rarely needed. Tim Peters <wink> said that with the hundred
> > cases of the beloved "x and y or z" idiom in the 150+ modules of
> > Python it's needed exactly 0 (zero) times.
>
> Nope. I said the relative handful of examples I included didn't need
> short-circuiting, and that it was rarely needed.
Yup, i mixed up.
> [good examples of and/or short-circuit usage in standard lib]
> In the end, I didn't find any code in the std library I'd change if the PEP
> were to be accepted. I didn't study every line, though.
That is still a good point.
Easy to get confused these days. I should stop posting to this
thread for a while. It's almost getting an addiction and everything
else than PEP-308 suddenly seems to uninteresting <self.wink>.
holger
Robin Munn
Almost, but not *quite*, what I wanted to suggest. I propose:
(x if C else y) # Parentheses are *required*
This is identical to the format proposed in PEP 308 with the exception
that parentheses are required around the ternary expression.
Rationale:
* It is reminiscent of list-comprehension syntax. Alex Martelli's
suggestion is even more so, of course, but I think it has the
potential to cause confusion. We have [x for x in l] syntax for list
comprehensions, something similar using {} for dictionary
comprehensions. What's left? Parentheses.
* The syntax is virtually the *same* as that proposed in PEP 308, which
I consider to be pretty Pythonic: it's easily understood in one
reading and pretty much unambiguous.
* This syntax is even more easy to read (IMHO) than the PEP 308 syntax;
the required parentheses automatically mark it off as a single
expression.
If this is adopted, the question then arises of what do with statements
like the following:
x1 if C1 else x2 if C2 else x3 if C3 else xdefault
Two possibilities exist:
(x1 if C1 else (x2 if C2 else (x3 if C3 else default)))
or:
(x1 if C1 else x2 if C2 else x3 if C3 else default)
The first is a natural extension of the required-parentheses rule, but
the second reads more like a single switch-like construction.
Even if this proposal is not accepted but PEP 308 is, I will still write
all my ternary-conditionals with parentheses around them; I believe that
good style will demand it.
--
Robin Munn <rm...@pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838 50FF 2478 CFFB 081A 8338 54F7 845D ACFD 6AFB 6838
James J. Besemer
Michele Simionato wrote:
> Erik, thanks for offering your time to prepare the list.
Yes, thanks.
> However, I think we
> should first make sure that there is a majority of Pythonistas favorable to
> the introduction of the ternary operator. There is no point in arguing
> between us about the more pythonic solution if 80% of users are already
> against the ternary operator.
I disagree in the strongest possible terms.
A majority might well vote against the PEP as stands today. In the absence
of the best possible syntax, voting NO might be the right answer. But many
people have indicated by their posts that they don't fully understand the
concept. Sheesh, 500+ emails into the discussion people were still
indicating that they didn't 'get' that the construct short circuits, and thus
cannot be defined as an ordinary function call.
Now (some 1500+ messages later) I sense that we've made some progress since
Guidio's original post in narrowing the field of alternatives, and killing
off some dead ends. But we're far from consensus and seems there's plenty
more to be discussed.
Anyway, per the PEP on PEPs, discussing and revising the PEP is a normal part
of the process before voting ocurrs. Building consensus is an express part
of the process.
Thus I view motions to vote prematurely as an underhanded attempt to kill the
proposal by bypassing the normal procedure.
There is no RUSH. We have plenty of time to work this out.
Regards
--jb
--
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:j...@cascade-sys.com
http://cascade-sys.com
James J. Besemer
Michele Simionato wrote:
> I did not want an official vote, I wanted a pre-screening, because I
> fear there is
> a large number of people who would say "no" to any proposal.
I have no objection to "straw man" votes, so long as they do not end the debate.
I also reiterate my concern that premature votes may result in votes being
unfairly skewed to the negative.
Michele Simionato
>
> Michele Simionato wrote:
>
> > Erik, thanks for offering your time to prepare the list.
>
>
> > However, I think we
> > should first make sure that there is a majority of Pythonistas favorable to
> > the introduction of the ternary operator. There is no point in arguing
> > between us about the more pythonic solution if 80% of users are already
> > against the ternary operator.
>
>
> A majority might well vote against the PEP as stands today. In the absence
> of the best possible syntax, voting NO might be the right answer. But many
> people have indicated by their posts that they don't fully understand the
> concept. Sheesh, 500+ emails into the discussion people were still
> indicating that they didn't 'get' that the construct short circuits, and thus
> cannot be defined as an ordinary function call.
>
> Now (some 1500+ messages later) I sense that we've made some progress since
> Guidio's original post in narrowing the field of alternatives, and killing
> off some dead ends. But we're far from consensus and seems there's plenty
> more to be discussed.
>
> Anyway, per the PEP on PEPs, discussing and revising the PEP is a normal part
> of the process before voting ocurrs. Building consensus is an express part
> of the process.
>
> Thus I view motions to vote prematurely as an underhanded attempt to kill the
> proposal by bypassing the normal procedure.
>
> There is no RUSH. We have plenty of time to work this out.
>
> Regards
>
>
> --
> James J. Besemer 503-280-0838 voice
> 2727 NE Skidmore St. 503-280-0375 fax
> Portland, Oregon 97211-6557 mailto:j...@cascade-sys.com
> http://cascade-sys.com
I did not want an official vote, I wanted a pre-screening, because I
fear there is
a large number of people who would say "no" to any proposal.
Of course, if the situation is (situation 1)
20% no
60% maybe
20% yes
then it is relevant to discuss a good new proposal such to convince that
60%.
However, if the situation is (situation 2)
60% no
20% maybe
20% yes
then there is no point to spend weeks in trying to convince people who
have already
decided. I have no idea if we are in situation (1) or situation (2),
because of the
"silent majority" that doesn't post. That's way I would like to see a
prescreening.
I hate the idea of spending the next week sending 100 postings to
convince people than
"when" is better than "if", if already the majority doesn't want the
ternary operator
in any form (and maybe this is the case; or maybe not, I don't know)
--
Michele Simionato - Dept. of Physics and Astronomy
210 Allen Hall Pittsburgh PA 15260 U.S.A.
Phone: 001-412-624-9041 Fax: 001-412-624-9163
Home-page: http://www.phyast.pitt.edu/~micheles/
Samuele Pedroni
"Michele Simionato" <mi...@pitt.edu> ha scritto nel messaggio
news:mailman.104491153...@python.org...
> I hate the idea of spending the next week sending 100 postings to
> convince people than
> "when" is better than "if", if already the majority doesn't want the
> ternary operator
> in any form (and maybe this is the case; or maybe not, I don't know)
The debate is already going circular.
Half-joking: I could vote no just because I had to suffer the debate <.5
wink>
And if it goes longer ...
Many on the pro-camp are crystallizing toward the proposal they like, I
would vote no just to avoid the risk of some of them.
And BTW we are essentially not discussing new functionality.
Erik Max Francis
> Almost, but not *quite*, what I wanted to suggest. I propose:
>
> (x if C else y) # Parentheses are *required*
>
> This is identical to the format proposed in PEP 308 with the exception
> that parentheses are required around the ternary expression.
The immediate reaction to this is that it doesn't seem fair in cases
like:
f((x if C else y))
(without the doubled parentheses, it would be illegal). If you want to
special-case that one, then the grammar gets more complicated and
eventually you start wondering why the parentheses should be required
anyway.
Use parentheses for clarity, sure. _Require_ them, I don't see.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Whoever contends with the great sheds his own blood.
\__/ Sa'di
Polly Wanna Cracka? / http://www.pollywannacracka.com/
The Internet resource for interracial relationships.
Michele Simionato
> Michele Simionato wrote:
> >
> > Erik, thanks for offering your time to prepare the list. However, I think we
> > should first make sure that there is a majority of Pythonistas favorable to
> > the introduction of the ternary operator. There is no point in arguing
> > between us about the more pythonic solution if 80% of users are already
> > against the ternary operator.
>
> I would think you could consider Erik's efforts to be focusing on
> the secondary question of "how to do it", just for that potential
> 20% (which is likely larger, but that's another story) who do want
> the ternary operator.
>
> Don't stop someone who already knows he wants it from putting
> together a list that will help likeminded people agree on the
> preferred syntax for that operator.
> > I think there is a big majority not
> > posting on c.l.p that could be contrary to the innovation and don't
> > bother to sent verbose postings. I fear this majority could kill
> > us at the voting moment (and maybe Guido counts on that).
>
> "counts on that"? That ascribes a somewhat underhanded approach
> to this whole thing to someone who appeared to be very open and
> upfront about the whole issue. Or am I misinterpreting your comment?
Guido could have added the ternary operator 10 years ago. He didn't. Now,
there are three possibilities:
1) he thinks that now it would be more useful than ten years ago, since
now we have listcomp, lambdas etc. Still it is not 100% convinced and he
is asking for feedback.
2) he doesn't want it, but since people has kept requisting it for ten
years, he is willing to concede it for peace of mind. He doesn't think
it would be too much harmful.
3) he really thinks most pythonistas don't want it. If the votation is
80% against, he has a good reason to refute it forever.
I am not a mind reader, I don't know what Guido thinks. Sometimes I propend
for 1), sometimes for 2), sometimes for 3). Who knows ?
>I don't understand all the comments about who can be trusted
> to manage the voting, who has ulterior motives, etc... this
> isn't *that* big a deal, is it? This is the discussion phase,
> where people's opinions can be swayed (even repeatedly :-) and
> some of the sillier arguments can be eliminated. After the
> dust settles, either a consensus emerges, or the need to
> vote is clear and we can proceed to that step. It doesn't
> really seem we're there yet, to me.
>
> -Peter
We will see.
Michele
Erik Max Francis
> Because you've got a major ambiguity if the statement begins
> with an "if". That comment is in the PEP.
It's only an ambiguity if you insist that the two forms meet in the
middle. There's no reason to make this happen; simply keep things as
is, where an `if' keyword starting a statement always means an if
statement. Thus
if C: x else: y
as a standalone statement is SyntaxError (perhaps with a slightly more
helpful message attached). If you really wanted the conditional
operator, surround it in parentheses.
No ambiguity, since an if statement cannot possibly be preceded by an
open parenthesis. It only involves additions to the grammar, no
changes.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
Erik Max Francis
> iif(C, x, y)
>
> No, that's not a short-circuiting form.
Well, then it isn't PEP 308 alternative, and so doesn't belong on the
list.
Erik Max Francis
> Erik, thanks for offering your time to prepare the list. However, I
> think we
> should first make sure that there is a majority of Pythonistas
> favorable to
> the introduction of the ternary operator.
Well, it takes little effort to maintain a list, given that I've been
following all the threads anyway. I just want to be prepared with the
list in the event it gets that far.
My general impression is that the first vote will be about 50-50. But
if 50% of people want a conditional operator, that's an awful lot.
Erik Max Francis
> I would think you could consider Erik's efforts to be focusing on
> the secondary question of "how to do it", just for that potential
> 20% (which is likely larger, but that's another story) who do want
> the ternary operator.
Indeed. Even if the PEP is rejected before we get to the selected
phase, the information will still be useful.
> Don't stop someone who already knows he wants it from putting
> together a list that will help likeminded people agree on the
> preferred syntax for that operator.
My thinking as well. Real derision on which syntax should be chosen
would likely queer the deal if it actually got as far as Guido saying,
"Okay, I give in, we'll add a conditional operator, now what should it
look like?" and the pro-308 community falls to pieces.
I'm just trying to prepare a list so that if it gets that far we have
something to talk about. Indeed, even if the PEP fails _before_ it gets
to that point, it would be instructive to have the list of proposed
syntaxes in the PEP itself so that future people who want it will have a
basis to comment on. (Not that rejecting the PEP will stop the
frequently asked questions about conditional operators.)
Erik Max Francis
> I did not want an official vote, I wanted a pre-screening, because I
> fear there is
> a large number of people who would say "no" to any proposal.
I don't see how that's really any different from a vote, you're just
giving it a different name. If you're suggesting policy be based on the
"pre-screening," then that is for all intents and purposes a vote.
I'm just cataloguing the list of alternatives that were suggested
throughout these threads, and dividing them into categories like
"suggested, but not seconded," "suggested and seconded," and "more
generalized schemes."
This information will be useful whether or not PEP 308 is accepted or
rejected, and even if rejected, whether it's rejected early or late.
I'm just collecting a list of alternatives, not votes. Even if
rejected, including the proposed forms in one place (that is, in the PEP
itself) will be instructive for posterity.
Besides, if it's all a waste of time, it's my time to waste, and the
amount of time I'm wasting by maintaining the list pales in comparison
to the amount of time I'm spending actively contributing to these
threads.
Erik Max Francis
> I have no objection to "straw man" votes, so long as they do not end
> the debate.
I'm not familiar with that term in this context. Did you mean "straw
poll"?
Aahz
>>
>> iif(C, x, y)
>>
>> No, that's not a short-circuiting form.
>
>Well, then it isn't PEP 308 alternative, and so doesn't belong on the
>list.
<shrug> I believe it's an alternative; if you refuse to list it, you've
got a guaranteed -1 from me.
Tim Peters
> The immediate reaction to this is that it doesn't seem fair in cases
> like:
>
> f((x if C else y))
>
> (without the doubled parentheses, it would be illegal). If you want to
> special-case that one, then the grammar gets more complicated and
> eventually you start wondering why the parentheses should be required
> anyway.
>
> Use parentheses for clarity, sure. _Require_ them, I don't see.
It seems little-known that Guido implemented conditional expressions for
Python about two years ago:
http://www.python.org/sf/471421
One of his patch comments there:
It's hairier than expected because I'm trying to require you to
put parentheses around it in some cases but not in others.
See the patch for more.
holger krekel
> John Roth wrote:
>
> > Because you've got a major ambiguity if the statement begins
> > with an "if". That comment is in the PEP.
>
> It's only an ambiguity if you insist that the two forms meet in the
> middle. There's no reason to make this happen; simply keep things as
> is, where an `if' keyword starting a statement always means an if
> statement. Thus
>
> if C: x else: y
>
> as a standalone statement is SyntaxError (perhaps with a slightly more
> helpful message attached). If you really wanted the conditional
> operator, surround it in parentheses.
>
> No ambiguity, since an if statement cannot possibly be preceded by an
> open parenthesis. It only involves additions to the grammar, no
> changes.
Not true but Andrew Koenig (probably) found a way to make this happen
(changing the grammar and adding to it).
holger
Dan Schmidt
| My general impression is that the first vote will be about 50-50.
| But if 50% of people want a conditional operator, that's an awful
| lot.
Yeah, but if 50% of people think that the conditional operator is so
terrible that they're not even willing to allow other people to use
it, that's an awful lot too.
Dan
James J. Besemer
Erik Max Francis wrote:
> "James J. Besemer" wrote:
>
>
>>I have no objection to "straw man" votes, so long as they do not end
>>the debate.
>
>
> I'm not familiar with that term in this context. Did you mean "straw
> poll"?
>
Yes.
From my experience many, many years ago on the ANSI X3J11 standards
committee, when discussing new features, the leaders called for non-binding
"straw votes" frequently to help move the discussion forward. It's a way to
quickly table identifiable dead-ends and help pare down otherwise impossible
lists of alternatives.
Regards
Bengt Richter
>On Sun, 09 Feb 2003 16:22:38 -0800, rumours say that Erik Max Francis
><m...@alcyone.com> might have written:
>
>>Here is the list I have so far (C represents the conditional expression,
>>x the if-true expression, y the if-false one):
>>
>>x if C else y # initial proposition in PEP
>>C ? x ! y # mentioned in PEP
>>(if C then x else y) # mentioned in PEP
>>x when C else y
>>(if C: x else: y)
>>C ? x else y
>>C -> x else y
>>C -> (x, y)
>>
>>What else should be on this list? (You can reply by email if you wish.)
>
>C then x else y
C -> x -> y
This is a concise ternary based on a larger concept (from lisp via Paul Moore with my twist):
the concept was [C1 -> v1; C2 -> v2; C3 -> v3; True -> vDefault] I.e., evaluate Ci's until
you find one that's true, then evaluate its companion v. My twist is to drop the brackets
and supstitute '><' instead of ';'. Thus
C1 -> v1 >< C2 -> v2 >< C3 -> v3 >< True -> vDefault
with a single condition, you have
C1 -> v1 >< True -> vDefault
and by making the final condition introducer '><' and its condition (True) optional, you get
C1 -> v1 -> vDefault
which expresses the ternary nicely without keywords.
Regards,
Bengt Richter
David Gausebeck
>>>the debate.
>>
>> I'm not familiar with that term in this context. Did you mean "straw
>> poll"?
>
>Yes.
>
> From my experience many, many years ago on the ANSI X3J11 standards
>committee, when discussing new features, the leaders called for non-binding
>"straw votes" frequently to help move the discussion forward. It's a way to
>quickly table identifiable dead-ends and help pare down otherwise impossible
>lists of alternatives.
What I'd be curious about at this point is how everyone breaks down
between:
1) I don't want conditional expressions added to python with any
syntax
2) I don't necessarily object to conditional expressions, but I don't
like and wouldn't support any syntax proposed so far
3) I'm in support of PEP 308 as written, but I wouldn't support any of
the other proposed syntaxes
4) I'd support PEP 308 as written, and I prefer it to any of the
proposed alternatives, but I could support some of the alternatives
as well
5) I would prefer one of the proposed alternate syntaxes to the
original PEP, but if it comes down to just yes/no on PEP 308, I
would vote yes
6) I would support one or more of the proposed alternate syntaxes, but
not PEP 308 as written
This can be looked at in a few interesting ways:
1-2: don't want anything suggested so far
3-4: want PEP 308 as written
5-6: want one of the alternate proposals
1-2,6: would vote no on PEP 308 as written
3-5: would vote yes on PEP 308 as written
1-3: wouldn't support any of the alternate syntaxes
4-6: would support at least one alternate syntax
However, starting a new poll whenever someone is curious is a good way
to drown out any useful information and dilute the chance of running
the polls that would really be useful. But if others think this would
be a useful poll, go ahead and run it and I'd love to see the results.
-Dave
Nick Vargish
> What else should be on this list? (You can reply by email if you wish.)
It requires a new keyword, but how about
C then x else y
with the else clause being mandatory. Alternately
C then: x else: y
As far as possible new keywords go, I'll guess that 'then' is not
commonly used as a variable name. I expect this will get shot down,
though -- I've noticed a certain resistance to the addition of new
keywords.
What I'd really like is to have the conditional come first, and avoid
overloading the 'if' keyword. Obviously else is already overloaded,
and fits nicely in context.
Nick
--
# sigmask ||| version 0.2 ||| 2003-01-07 ||| Feed this to your Python.
print reduce(lambda x,y:x+chr(ord(y)-1),'Ojdl!Wbshjti!=obwAqbusjpu/ofu?','')
Nick Vargish
> C then x else y
Darnit. I knew I should have read the whole thread before piping up.
Laura Creighton
>
> | My general impression is that the first vote will be about 50-50.
> | But if 50% of people want a conditional operator, that's an awful
> | lot.
>
If the vote is 50/50 then we have done our poll wrong. The people
who don't care should get to vote that.
Laura
Laura Creighton
James J. Besemer
Laura Creighton wrote:
> If the vote is 50/50 then we have done our poll wrong. The people
> who don't care should get to vote that.
Sorry. I am not following you.
Erik Max Francis
> Not true but Andrew Koenig (probably) found a way to make this happen
> (changing the grammar and adding to it).
There's no ambiguity in what was proposed. That Corner Case is merely a
syntax error, just as it is now. The proposal adds, not changes.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ There I was / There I was / Splitting atoms with my desire
\__/ Lamya
Computer science / http://www.alcyone.com/max/reference/compsci/
A computer science reference.
Erik Max Francis
> Erik Max Francis wrote:
>
> > Aahz wrote:
> >
> > > No, that's not a short-circuiting form.
> >
> > Well, then it isn't PEP 308 alternative, and so doesn't belong on
> > the list.
>
> <shrug> I believe it's an alternative; if you refuse to list it,
> you've
> got a guaranteed -1 from me.
Are you really saying that you're going to vote against a PEP because of
what _I_ do in a non-authoritative capacity? I'm compiling a list for
my own edification and will present it to the community when the threads
die down; what goes into the PEP and/or any vote on syntax will be
decided by the community, not me. I submit that you voting -1 because
of what _I_ do will reflect far more on yor behavior and ethics than on
mine -- particularly given that you have been clearly and vocally
predisposed against the PEP from the very beginning.
Read the updated text of PEP 308. A non-short-circuiting function (in
this case, `cond') is specifically mentioned, and _explicitly rejected_
by the BDFL expressly because it does not short circuit:
4. Adopt a function without short-circuit behavior:
cond(<condition>, <expression1>, <expression2>)
...
The fourth position is much more conservative. Adding a new
function, cond(), is trivially easy to implement and fits easily
within the existing python model. Users of older versions of
Python will find it trivial to simulate. The downside is that
it does not provide the sought-after short-circuit
evaluation (see the discussion below on the need for this).
The bigger downside is that the BDFL opposes *any* solution that
does not provide short circuit behavior.
The ?: form is also explicitly rejected in the PEP, and thus is also not
in my list of alternatives (this has been true from the very beginning,
and I've pointed it out a few times in this thread). If you don't like
it, take it up with the BDFL.
Still going to vote -1 because of what _I_ do?
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
Laura Creighton
> Laura Creighton wrote:
>
> > If the vote is 50/50 then we have done our poll wrong. The people
> > who don't care should get to vote that.
>
> Sorry. I am not following you.
>
> --jb
When you are taking a poll to find out what the community thinks about
something, it matters a great deal if the results come out 48% for,
42% against, 10% abstained/undecided/don't care or if you get 6% for,
4% against 90% abstained/undecided/don't care. You mustn't take a
vote with the assumption that 'only people who care matter'. Those
that do not care have not automatically lost their franchise.
Laura
Bengt Richter
>This is a concise ternary based on a larger concept (from lisp via Paul Moore with my twist):
Regards,
Bengt Richter
Erik Max Francis
> If the vote is 50/50 then we have done our poll wrong. The people
> who don't care should get to vote that.
I have no problem with that provided everybody agrees on how it plays
into the voting process.
The problem I see with it is that people who don't care simply won't
bother voting (except to demonstrate proudly that they don't care), so
including it and trying to use that figure for something meaningful will
be misleading.
I think when it was suggested people vote on the question, "Do you want
a short-circuiting conditional operator to be added to Python, yes or
no?" explicitly is directed at the people who _do_ care one way or
another.
You'll never know how many don't care but didn't vote, so I'm not sure
if trying to include that as an option in the vote is really going to
get you a figure that reflects reality.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I always entertain great hopes.
\__/ Robert Frost
REALpolitik / http://www.realpolitik.com/
Get your own customized newsfeed online in realtime ... for free!
Erik Max Francis
> When you are taking a poll to find out what the community thinks about
> something, it matters a great deal if the results come out 48% for,
> 42% against, 10% abstained/undecided/don't care or if you get 6% for,
> 4% against 90% abstained/undecided/don't care. You mustn't take a
> vote with the assumption that 'only people who care matter'. Those
> that do not care have not automatically lost their franchise.
I feel I should point out that in Usenet CFVs, abstensions carry no
weight whatsoever and never affect the voting outcome. The point is
particularly important for Usenet CFVs, but I think it applies here too.
I mean think about it, when someone posts a vote for
rec.pets.gardening.babylon5 or some other specialized newsgroup, the
vast majority of Usenet readers simply don't care. You can never
measure their numbers, but you can rest assured that they will vastly
outnumber the piddly numbers of people who vote for the proposal. So
voting Abstain in a CFV has no weight whatsoever, just like all those
thousands of people who didn't care about the group and didn't bother
voting.
There's an analogy with Python here, although within the Python
community, obviously, the ratio of "don't cares" to "cares" will
probably be much lower. My point is, you can never measure the "don't
cares," so having a "don't care" on the ballot seems guaranteed to
produce unreliable results. Only the don't cares that actually _do_
care about their not caring will vote, if you catch my meaning.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
James J. Besemer
Erik Max Francis wrote:
> I feel I should point out that in Usenet CFVs, abstensions carry no
> weight whatsoever and never affect the voting outcome. The point is
> particularly important for Usenet CFVs, but I think it applies here too.
Yeah, explicit +0 or -0 certainly should count but people who don't bother to
express an opinion -- it's unclear what significance to attach to it.
Laura Creighton
>
> > If the vote is 50/50 then we have done our poll wrong. The people
> > who don't care should get to vote that.
>
> I have no problem with that provided everybody agrees on how it plays
> into the voting process.
>
> The problem I see with it is that people who don't care simply won't
> bother voting (except to demonstrate proudly that they don't care), so
> including it and trying to use that figure for something meaningful will
> be misleading.
No, that is only the people who don't care enough to vote. It is a
problem with _voting_, and the self selected set, and an insoluable
one, unless you have a mechanism for forcing people to vote. That
has its own problems.
> I think when it was suggested people vote on the question, "Do you want
> a short-circuiting conditional operator to be added to Python, yes or
> no?" explicitly is directed at the people who _do_ care one way or
> another.
>
> You'll never know how many don't care but didn't vote, so I'm not sure
> if trying to include that as an option in the vote is really going to
> get you a figure that reflects reality.
It has got to reflect reality better than simply assuming that those
who do not care do not matter, or that those who wish to participate
in the political process must be forced to take sides, or that
abstainers fall neatly into 50% pro/ 50% anti proportions. It also
means that the entire political process is not subordinate to the job
of 'picking winners and losers' ... it actually represents an attempt,
however flawed, to 'find out what people want'. You alienate members
of your society when you hold a vote and give them no way to express
their views. I think that this is evil, and moreover, it makes it
really hard to get them to show up again should you ever decide
to have _another_ referendum.
I'm-voting-one-referendum-is-already-more-than-we-needed,
Laura
> --
> Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
> __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
> / \ I always entertain great hopes.
> \__/ Robert Frost
> REALpolitik / http://www.realpolitik.com/
> Get your own customized newsfeed online in realtime ... for free!
Erik Max Francis
> It has got to reflect reality better than simply assuming that those
> who do not care do not matter, or that those who wish to participate
> in the political process must be forced to take sides, or that
> abstainers fall neatly into 50% pro/ 50% anti proportions. It also
> means that the entire political process is not subordinate to the job
> of 'picking winners and losers' ... it actually represents an attempt,
> however flawed, to 'find out what people want'. You alienate members
> of your society when you hold a vote and give them no way to express
> their views. I think that this is evil, and moreover, it makes it
> really hard to get them to show up again should you ever decide
> to have _another_ referendum.
I have no objection to including "don't cares" in the voting process,
provided it's included in a way such that everyone is satisfied with the
process.
I was simply pointing out that there are _always_ an implied _huge_
contingent of "don't cares" in any vote, and so if you include a special
"abstain" vote, the question boils down to what that should mean in the
final figures. The real number of people who don't care will certainly
be much greater than the number of "abstain" votes that get sent;
admittedly, in many cases, it might even be much greater than the total
number of yes and no votes (as would certainly be the case with Usenet
CFVs).
The "don't care" camp is _going_ to get underrepresented in any vote, so
the question is what value or relevance should abstentions should have
in the process.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Nothing is so good it lasts eternally
\__/ Florence, _Chess_
Erik Max Francis' bookmarks / http://www.alcyone.com/max/links/
A highly categorized list of Web links.
Christos TZOTZIOY
<n...@adams.patriot.net> might have written:
>Darnit. I knew I should have read the whole thread before piping up.
Nick,
this is not my idea either; it was mentioned in the initial PEP by Guido
as
if C then x else y
only to be rejected for ambiguity; my remark (and others') is that the
'if' can be dropped, while 'then' needs not be a keyword (ie it pops up
in the middle of an expression, and look-ahead of depth 1 in Python's
parser allows special use of 'then' only in expressions).
However, I don't mind. I'm +0 anyway. If a ternary conditional
operator is there, I'll use it (heck, I don't mind even the 'x if C else
y') instead of "C and x or y" with its one glitch.
Why so much fuss, anyway? I've been a C programmer for years, and I
used its ternary operator often (when I thought it appropriate); my
coding style was always dense (see patch 681780, as an example of Python
code that is not so obvious but is fast; I guess it will probably be
dropped though), being kind of a 'lone wolf' for years, and I based the
readability of my code on comments (ie, "this block does this; now move
on to the next block"). I am aware of the problems dense code creates
when co-operating with people, and the readability of Python was one of
the things that enchanted me with the language. So I'm still learning
to code in a more readable way (I never did any XP so far).
The only reason to be on the plus side to add a "clear" ternary
conditional operator in python, is because the and-or trick already
exists. For someone who owned a ZX Spectrum (like me), it is familiar;
it is not for a newbie.
Guido must be getting mellow.
Or old.
Or wise.
Or all of the above. :)
--
TZOTZIOY, I speak England very best,
Real email address: 'dHpvdEBzaWwtdGVjLmdy\n'.decode('base64')
Roy Smith
Well, they're required for function calls. Surely you're not advocating
making them optional in that case?
Laura Creighton
>
> I have no objection to including "don't cares" in the voting process,
> provided it's included in a way such that everyone is satisfied with the
> process.
Well, you are never going to get that; people who think that people
who don't care should get no vote will be opposed to this no matter
what.
>
> I was simply pointing out that there are _always_ an implied _huge_
> contingent of "don't cares" in any vote, and so if you include a special
> "abstain" vote, the question boils down to what that should mean in the
> final figures. The real number of people who don't care will certainly
> be much greater than the number of "abstain" votes that get sent;
So will the real number that are pro, and the real number that are
anti.
> admittedly, in many cases, it might even be much greater than the total
> number of yes and no votes (as would certainly be the case with Usenet
> CFVs).
>
> The "don't care" camp is _going_ to get underrepresented in any vote, so
> the question is what value or relevance should abstentions should have
> in the process.
That isn't your decision. Otherwise we get government by 'the league
of concerned citizens' (unless the ad-hoc-vigillante posse of
unconcerned citizens tosses the aforementioned concerned citizens into
the moat).
Laura
Michele Simionato
> "Michele Simionato" <mi...@pitt.edu> ha scritto nel messaggio
> news:mailman.104491153...@python.org...
> > I hate the idea of spending the next week sending 100 postings to
> > convince people than
> > "when" is better than "if", if already the majority doesn't want the
> > ternary operator
> > in any form (and maybe this is the case; or maybe not, I don't know)
>
> The debate is already going circular.
>
> Half-joking: I could vote no just because I had to suffer the debate <.5
> wink>
> And if it goes longer ...
I think Samuele has expressed my worries very well. I fear a long discussion
with dozens of different proposals and threads will finally annoy people,
and make them more incline to the "no, thanks" party.
> Many on the pro-camp are crystallizing toward the proposal they like, I
> would vote no just to avoid the risk of some of them.
I understand very well this point. I wasn't seriously speaking when I said
"I will post 100 messages to convince people that 'then' is better than 'if'",
but I fear people will do so. This would go against the "yes" party.
BTW, I am still in the "yes" party, but having seen many ugly proposals
and the critiques of the "no" party, I must say that I am now in the
line "yes, but not to everything".
Unfortunately, at this point there is no way to slow-down the discussion :-(
Erik, what do you plan to do ? I guess, you want to set up a web-page
where people can vote the different proposals and see if there is a
proposal with a majority consensus (majority in the "yes" party, I
mean).
Cheers,
Michele
Michele Simionato
> Erik Max Francis <m...@alcyone.com> writes:
>
> > What else should be on this list? (You can reply by email if you wish.)
>
> It requires a new keyword, but how about
>
> C then x else y
>
> with the else clause being mandatory. Alternately
>
> C then: x else: y
>
> As far as possible new keywords go, I'll guess that 'then' is not
> commonly used as a variable name. I expect this will get shot down,
> though -- I've noticed a certain resistance to the addition of new
> keywords.
>
> What I'd really like is to have the conditional come first, and avoid
> overloading the 'if' keyword. Obviously else is already overloaded,
> and fits nicely in context.
>
> Nick
I was thinking to this possibility (without the colons).
Notice that "then" could be a pseudo-keyword analogous to "as". I
would support this more than
(if C: x else: y)
that I dislike since
1) overload "if"
2) it is too much similar to a statement.
In the last few days I have changed my mind and now I am against any
suggestion than could generate confusion between the "if" statement and
the conditional expression. This is because somebody pointed out the confusion
between
if C: print x
else: print y
(valid code)
and
(if C: print x
else: print y)
invalid code!
Michele
Tim Daneliuk
<SNIP>
>
> you need to add:
>
> 7) I don't care
>
>
> Laura
>
LOL - Put me down for this one too.
--
------------------------------------------------------------------------------
Tim Daneliuk
tun...@tundraware.com
Andrew Koenig
Erik> syntax error, just as it is now. The proposal adds, not changes.
That's not completely true: There are two changes to the names of
tokens in existing rules.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Robin Munn
>
>> Almost, but not *quite*, what I wanted to suggest. I propose:
>>
>> (x if C else y) # Parentheses are *required*
>>
>> This is identical to the format proposed in PEP 308 with the exception
>> that parentheses are required around the ternary expression.
>
> The immediate reaction to this is that it doesn't seem fair in cases
> like:
>
> f((x if C else y))
>
> (without the doubled parentheses, it would be illegal). If you want to
> special-case that one, then the grammar gets more complicated and
> eventually you start wondering why the parentheses should be required
> anyway.
>
> Use parentheses for clarity, sure. _Require_ them, I don't see.
And if parentheses aren't required, then that might be the one case
where I would consider leaving them out. Nevertheless, I still think
required parentheses are a good idea. I don't see much significant
difference between:
f((x if C else y))
and:
f([x for x in L])
List comprehensions are required to be enclosed by punctuation pairs,
even though it would be possible to parse them without those enclosing
brackets (the presence of "for" after an expression being what would
trigger the parser that this is a list comprehension). I wasn't reading
python-dev at the time when list comprehension syntax was being
discussed, but I can't imagine too many people wanting to omit the
brackets:
x for x in L <-- a (hypothetical) bracketless list comprehension
[x for x in L] <-- same thing with the brackets
The second one scans much better, IMHO. My eye can take in the
bracket-enclosed section as a single unit, recognize it as a list
comprehension, and parse it. Whereas the first format makes me do a
double-take and needs two slow passes to scan. First pass: "OK, the
value is x, wait a minute, there's a for. That's a list comp. OK, find
the end of the list comp..." Then back to the beginning for a second
pass to actually read meaning. If we require parentheses around ternary
expressions, I think it will have a similar effect:
x if C else y
(x if C else y)
Again, I think the second one just scans better.
OTOH, I'm not entirely convinced myself that it's necessary to require
the parentheses. Good style will demand that they be there, yes. And
I'll strongly recommend them to newbies who ask for help with their code
six months down the line. ("Strongly recommend" here means: "By the way,
that ternary expression really needs parentheses around it. It's the
accepted coding standard, and anything else looks desperately ugly.")
But I'm not certain that this is a case where we really need the parser
to enforce good style. Maybe we should take the "we're all adults here"
approach and let people leave off the parentheses as they see fit, while
still recommending (strongly) that parentheses be placed around a
ternary expression unless you have a darn good reason to do otherwise.
Look at that. I've managed to argue so convincingly against my own
position that I'm now -0 on my own idea. :-)
--
Robin Munn <rm...@pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838 50FF 2478 CFFB 081A 8338 54F7 845D ACFD 6AFB 6838
Dave Brueck
> > You'll never know how many don't care but didn't vote, so I'm not sure
> > if trying to include that as an option in the vote is really going to
> > get you a figure that reflects reality.
>
> It has got to reflect reality better than simply assuming that those
> who do not care do not matter, or that those who wish to participate
> in the political process must be forced to take sides, or that
> abstainers fall neatly into 50% pro/ 50% anti proportions. It also
> means that the entire political process is not subordinate to the job
> of 'picking winners and losers' ... it actually represents an attempt,
> however flawed, to 'find out what people want'. You alienate members
> of your society when you hold a vote and give them no way to express
> their views. I think that this is evil, and moreover, it makes it
> really hard to get them to show up again should you ever decide
> to have _another_ referendum.
Laura, I find your perspective facinating but I still don't quite "get it"
(please don't think I'm being sarcastic - I'm *really* trying to
understand you but haven't yet). Can you explain a little more what you
mean?
When there's a bunch of us deciding to order pizza, I'll often not vote
because I don't care. Since the point of voting is to come to a decision,
how would tracking my "don't care" vote affect the decision? In effect I
_am_ casting a vote - a vote to not participate - so that the people who
_do_ care about the influence can work it out amongst themselves.
The same holds true for political elections. Sometimes I don't vote
because I don't feel informed enough to make a good decision, other times
I don't vote because I don't really care either way, and sometimes I do
vote. But again I don't see how keeping track of an explicit "don't care"
matters - the whole point of the vote is to reach a decision, right?
(maybe your point is that it's not the whole point?) If there's a 0.5%
voter turnout, then you can infer just as [in]accurately that people don't
care about that particular issue, right? This is why "Get Out the Vote"
drives in the U.S. scare me - the encourage people who just don't care to
participate in making decisions. Yeah, I guess we could add a "don't care"
slot to the ballot, but why? What does that _mean_? How should it affect
the outcome?
FWIW, I am opposed to straight "democratic" voting anyway because the
quality of the decision is often rather poor (due to various factors). I'd
much rather vote to select a handful of "trusted" individuals - a healthy
mix of pro- and con PEPers, and let them go off and have an intelligent
debate, and then accept what they come back with, but maybe that's a topic
for a different discussion.
Thanks for your patience,
Dave
Dave Brueck
> > What I'd really like is to have the conditional come first, and avoid
> > overloading the 'if' keyword. Obviously else is already overloaded,
> > and fits nicely in context.
> >
> > Nick
>
> I was thinking to this possibility (without the colons).
> Notice that "then" could be a pseudo-keyword analogous to "as". I
> would support this more than
>
> (if C: x else: y)
>
> that I dislike since
>
> 1) overload "if"
Out of curiosity, in what way is "if" overloaded? The reason I like 'if'
in this context is because it means the _exact_ same thing it does in an
if-statement: a condition is about to be checked in order to make a binary
desicion. Because it means the same thing as it does in an if-statement,
it's so much easier to guess the meaning if you're not familiar with it.
The colon and (usually) indentation is what marks the beginning of a block
of code under an 'if', not the 'if' itself.
-Dave
Dave Brueck
> OTOH, I'm not entirely convinced myself that it's necessary to require
> the parentheses. Good style will demand that they be there, yes. And
> I'll strongly recommend them to newbies who ask for help with their code
> six months down the line.
And I think that this attitude is key: any new language feature should
include some "good style" guidelines that, while not enforced by the
language, carry nearly the same weight. This is especially important when
the PEP needs to list, for clarity and completeness, what happens in
oddball use cases - a style section balances what's possible with what's
reasonable.
A lot of arguments against the PEP deal with odd abuses of the feature,
but IMO they overexaggerate the risks there. Most developers with even a
little discipline will avoid such uses, and if they don't care about good
style then they will write sloppy code despite what the language
encourages.
If your company has a coding standard _and_ abuse becomes a problem, you
can add it to your coding standard (with emphasis on waiting for it to
really become a problem). At my current job we don't have a formal
standard at all, but every once in awhile we'll make style suggestions to
each other and it's the end of the issue. Not a big deal!
-Dave
Andrew Koenig
Robin> case where I would consider leaving them out. Nevertheless, I
Robin> still think required parentheses are a good idea. I don't see
Robin> much significant difference between:
Robin> f((x if C else y))
Robin> and:
Robin> f([x for x in L])
I do. Enclosing list comprehensions in brackets makes it clear that
they're generating lists. In fact, I had to check to see that it
wasn't possible to write (x for x in L) as a tuple comprehension,
which is what I would have expected it to mean if it meant anything.
On the other hand, I don't see much difference between
f(x if C else y)
and
f(lambda x: x+1)
in which extra parentheses are already not required.
Anders J. Munch
> The immediate reaction to this is that it doesn't seem fair in cases
> like:
>
>
> special-case that one, then the grammar gets more complicated and
> eventually you start wondering why the parentheses should be required
> anyway.
It doesn't particularly complicate the grammar to require parentheses
but allow
f(x if C else y)
It may even be simpler than not requiring parentheses because there's
no need to consider ambiguities with if statements and within list
comprehensions.
- Anders
Andrew Koenig
Erik> keyword `ifelse'? Why not use `if'?
John> Because you've got a major ambiguity if the statement begins
John> with an "if". That comment is in the PEP.
I believe I have eliminated the ambiguity.
Many people have suggested that it requires unbounded lookahead to
determine whether
if C: expr1 else: expr2
is a statement or an expression. After thinking about it for a while,
I suddenly realized that this claim is not true.
The key here is that a statement always ends with either a newline
or a dedent, and an expression never does. That means that when
you're parsing bottom-up, whenever it comes time to determine whether
a construct is an expression or a statement, you can always make that
determination by seeing whether the next symbol is a newline, a dedent,
or something else.
This surprising fact yields an even more surprising simplification
of my previous proposal for changing the grammar:
Original:
test: and_test ('or' and_test)* | lambdef
Proposed:
test: and_test ('or' and_test)* | lambdef | if_test
if_test: 'if' test ':' test ('elif' ':' test)* 'else' ':' test
In English: An if-else expression is permitted anywhere a lambda
expression is permitted, with the same precedence rules.
This change passes pgen without complaint.
Some implications:
if x==0: "foo" else: "bar" # legal expression
if x==0: "foo" # legal statement
else: "bar"
print if x==0: "foo" else: "bar" # legal statement
if x==0: print "foo" else: print "bar" # illegal, as it is today--
# print is not an expression
if x==0: print "foo" # legal statement, as it is today
else: print "bar"
if x==0: "foo" # legal statement, as it is today
else: "bar"
Samuele Pedroni
"Andrew Koenig" <a...@research.att.com> ha scritto nel messaggio
news:yu99isvqh...@europa.research.att.com...
brilliant, you've just made the problem worse!
Michele Simionato
As I said in some other thread, I want a clear distinction between the
"if" statement and the conditional expression. They cannot be distinguished
by a parenthesis only:
if C: print x
else: print y
is correct whereas
(if C: print x
else: print y)
would be a syntax error! (I am quoting an example from another poster).
Max M. said (and I 100% agree with him):
"""
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. """
Moreover, I hate to call a function with
f((if C: x else: y))
and I hate the next unavoidable step
(try: X except: Y)
etc.etc.
Why to go over all this trouble when we have
C then x else y
without parenthesis, colons, if and with "then" not a keyword ?
Nick Vargish
> However, I don't mind. I'm +0 anyway.
I'm pretty much +0 myself. Some of the syntax suggestions put me in -1
territory, though, which is why I piped up. Since I don't much care
if it's added or not, but I do care _how_ it's added if it is, I
figured I say something (lest I be counted as a plain "don't care"
:^).
Nick
--
# sigmask ||| version 0.2 ||| 2003-01-07 ||| Feed this to your Python.
print reduce(lambda x,y:x+chr(ord(y)-1),'Ojdl!Wbshjti!=obwAqbusjpu/ofu?','')
Dave Brueck
> > Out of curiosity, in what way is "if" overloaded? The reason I like 'if'
> > in this context is because it means the _exact_ same thing it does in an
> > if-statement: a condition is about to be checked in order to make a binary
> > desicion. Because it means the same thing as it does in an if-statement,
> > it's so much easier to guess the meaning if you're not familiar with it.
> >
> > The colon and (usually) indentation is what marks the beginning of a block
> > of code under an 'if', not the 'if' itself.
>
> As I said in some other thread, I want a clear distinction between the
> "if" statement and the conditional expression. They cannot be distinguished
> by a parenthesis only:
>
> if C: print x
> else: print y
>
> is correct whereas
>
> (if C: print x
> else: print y)
>
> would be a syntax error!
Yes, but for at least two good reasons: multiline expressions in Python
require '\' to join the lines (and this shold be no exception) and 'print'
is a statement - there's no risk for hidden bugs because the code won't
even compile (and that's a good thing).
As to it would be confusing because they appear to differ only by parens,
you're leaving out the context in which they'd be used, and although the
parens are important, the actual context is even more important in
determining meaning. In an if-statement, the 'if' is what you see first.
Way, way, way on the other side of the spectrum you'd realistically never
see a conditional expression, in any of the proposed forms, as the first
thing on a line. The most common case is likely to be of the form:
x = (if ...)
So in reality there _is_ a clear distinction between the two.
> 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.
... and emphasis/clarity and overriding precedence rules. This is how
they're used today and the above example is no exception.
> Moreover, I hate to call a function with
>
> f((if C: x else: y))
Me too. IIRC the "parens required" form is losing popularity anyway.
> C then x else y
>
> without parenthesis, colons, if and with "then" not a keyword ?
Hehehe... it turns out we agree more than not! I don't disagree with you
in that respect - the above is one of my favorites so far (I just didn't
find a problem using 'if' again) and since the original PEP version is
losing favor I'll probably be casting my vote for the C then x else y
version. :)
-Dave
Samuele Pedroni
"Samuele Pedroni" <pedr...@bluewin.ch> ha scritto nel messaggio
news:3e4951cc$1...@news.bluewin.ch...
>
> brilliant, you've just made the problem worse!
AK> How so?
You consider having a conditional expression looking like the statement a
feature and you have worked to _technically_ solve the parser, language
definition details to have it so...
I consider that possibility a mixed bless, I would rather (if we should have
one) have a conditional operator that looks operatorial and in the same
family
of 'and'/'or'. Why?
Because the fact that Python distinguishes statements and expressions is
basically, apart from being the status quo and what is implemented, a
_deliberate_ decision, that happens to work well together with
indentation-delimited blocks.
[OTOH is probably not impossible to conceive a language that mixes
indentation
usage and () usage as delimiters and where everything is an expression and
produces a value]
Having a conditional expression that looks like a statement will touch this
very nerve ...
and will blur the distinction from the hand-on experience of the language
(of
course not from the lang ref POV).
I prefer not to be confronted (if possible) with the questions:
"Why this does not work?" with this being:
if x: (print x)
(for x in l: print l)
...
if x>0: print "pos" else: print "negative"
they make no sense from the lang ref/lawyer perspective. But if the asker
is
naive/confused/a troll/impertinent:
answering ye we have this two things that look the same but one is a
statement
and one is an expression and we disambiguate them so, put in [clever
explanation], but we are for statement/expression distinction and RTFM
is a kind of "cheap bastard" attitude, because the fact that the above are
invalid is also a matter of _deliberate_choice, so we would have to go
philosophical and discuss this is "pythonic" and this not and the
statement/expression distinction thing, and argue about readability ...
so if possible I would rather avoid this, thanks.
Paul Rubin
> I consider that possibility a mixed bless, I would rather (if we should have
> one) have a conditional operator that looks operatorial and in the same
> family
> of 'and'/'or'. Why?
>
> Because the fact that Python distinguishes statements and expressions is
> basically, apart from being the status quo and what is implemented, a
> _deliberate_ decision, that happens to work well together with
> indentation-delimited blocks.
Algol-60 made the same distinction, yet allowed if-else in arithmetic
expressions similar to this proposal. Are you saying this was a
shortcoming in Algol-60? I never thought of it as one. (I've written
some Algol-60 code, though not an enormous amount).
Andrew Koenig
>> else: print y
>>
>> is correct whereas
>>
>> (if C: print x
>> else: print y)
>>
>> would be a syntax error!
Dave> Yes, but for at least two good reasons: multiline expressions in
Dave> Python require '\' to join the lines (and this shold be no
Dave> exception) and 'print' is a statement - there's no risk for
Dave> hidden bugs because the code won't even compile (and that's a
Dave> good thing).
Multiline expressions don't require '\' to join them if the newline
appears at a point where parentheses are unbalanced.
Evan Simpson
> As I said in some other thread, I want a clear distinction between the
> "if" statement and the conditional expression. They cannot be distinguished
> by a parenthesis only:
"Cannot" in what sense? The grammar can handle it.
> if C: print x
> else: print y
>
> is correct whereas
>
> (if C: print x
> else: print y)
>
> would be a syntax error!
Properly so. Why do you consider this to be a problem?
> And what is this with parens that has to be there? This is so
> inconsistent with how parens are used normally in Python.
Function calls and defs require parens, tuple parens are optional, class
bases require parens. Parens can also group expressions. Where is the
consistency that is being violated, and what cost do you imagine that
breaking it would impose?
> Moreover, I hate to call a function with
>
> f((if C: x else: y))
Do you also hate "f((x,))" to pass a one-tuple to a function?
> and I hate the next unavoidable step
>
> (try: X except: Y)
"Unavoidable"? You've lost me.
> Why to go over all this trouble when we have
>
> C then x else y
>
> without parenthesis, colons, if and with "then" not a keyword ?
This isn't too bad, if it can be made to work. Having a magical
non-keyword in the middle of an expression is hardly consistent with the
rest of Python, though. Between that and chaining, we can construct:
print now or then then then then then else now else "never"
In the spirit of your first objection above, we also have:
C then print x else print y
Cheers,
Evan @ 4-am
Bengt Richter
>
>
>Erik Max Francis wrote:
>
>> I feel I should point out that in Usenet CFVs, abstensions carry no
>> weight whatsoever and never affect the voting outcome. The point is
>> particularly important for Usenet CFVs, but I think it applies here too.
>
>Yeah, explicit +0 or -0 certainly should count but people who don't bother to
>express an opinion -- it's unclear what significance to attach to it.
>
Why don't we just set up a web page with all the alternatives listed
and checkboxes [-1] [-0] [+0] [+1] to click for each, and have cgi
format a response page with a concise email mailto link with parameters encoding
the vote info, so voters can just click the mailto link and have their local email
client pop up with vote parameters already set up in subject and/or body, and
all they have to do is send it.
Valid return addresses could be checked if desired with automated return mail and
confirmation, though that might be overkill. But in any case there would be no work
entering anything in the email itself, since all the parameters originate in the
submittal of the first web page form, and pass through the second web page via
cgi-prepared mailto parameters.
Hm... I just had an idea: what if we had a little bit of special syntax for PEP source
text so that it would be easy to generate a voting form web page like I just described?
The structured text stuff probably wouldn't need much of an extension (maybe they're
already there -- I haven't looked lately).
All you would need is something to flag the place to put the check boxes and to provide
an id tag for the check box data, and maybe where to put the submit button and how to label
it.
Doing this once would make PEP-voting setup a one-click thing from there on.
Maybe too easy ;-)
Regards,
Bengt Richter
Nick Vargish
> print now or then then then then then else now else "never"
I refuse to be baited by that. :^)
> C then print x else print y
This would be a syntax error. Try this:
>>> x = print 'Hello.'
See?
Nick
--
#include<stdio.h> /* SigMask 0.3 (sig.c) 19990429 PUBLIC DOMAIN "Compile Me" */
int main(c,v)char *v;{return !c?putchar(*v-1)&&main(0,v+ /* Tweaks welcomed. */
1):main(0,"Ojdl!Wbshjti!=obwAqbusjpu/ofu?\v\1");} /* build: cc -o sig sig.c */
Andrew Dalke
allows
a = if x: y() else: z()
This also means
# get the 2-ple of name's value and who owns it
a = (
# The value can be cached or in the database
if is_cached:
self._get_cache[name]
else:
self.connection.fetch(name), # get it from the database
# The ownership is stored in the database (if the
# name starts with "DB") or from the web service
if x.startswith("DB")
self.connection.get_owner(name)
else:
self.webservice.get_owner_by_name(name)
)
is valid, yes? That is, code which in the small looks like normal Python
if/else statement is really an if/else expression?
I don't like that.
Andrew
da...@dalkescientific.com
Carel Fellinger
...
> Laura, I find your perspective facinating but I still don't quite "get it"
> (please don't think I'm being sarcastic - I'm *really* trying to
> understand you but haven't yet). Can you explain a little more what you
> mean?
I'm no Laura, so I can't explain for here, so I'll add my own musings.
Let's not talk pizza's but Python here. And let's assume that there
are 100 Python users out there.
When 50 of those are pro and 50 are contra, then Guido has a problem:)
Whatever he decides will upset half the population.
On the otherhand, when 1 is pro and 1 is contra and all the others don't
care, then whatever he decides will be fine with the masses.
In the first case we'd better help him and try to convince the other
party that our view point* is the right one. In the other case we
might as wel stop now and tell Guido to throw dices instead:) More
seriously, when the pro's and contra's really are minority groups,
then it's probably best not to add questionable syntactic sugar
to the language.
*) contrary to what some might have deduced from my earlier posts,
I'm neither pro nor contra. I would use a better spelling for
the and/or idiom, but only when it still looked better to me eyes
after returning to my code after a few weeks. As it is now, I
often undo my cunnery and go back to simple if-statements, sometimes
to find myself redoing the cunnery after/during familiarizing myself
with the code again.
--
groetjes, carel
Bengt Richter
[...]
>Why don't we just set up a web page with all the alternatives listed
>and checkboxes [-1] [-0] [+0] [+1] to click for each, and have cgi
Regards,
Bengt Richter
Dave Brueck
> On Tue, Feb 11, 2003 at 08:23:37AM -0800, Dave Brueck wrote:
> ...
> > Laura, I find your perspective facinating but I still don't quite "get it"
> > (please don't think I'm being sarcastic - I'm *really* trying to
> > understand you but haven't yet). Can you explain a little more what you
> > mean?
>
> I'm no Laura, so I can't explain for here, so I'll add my own musings.
>
> Let's not talk pizza's but Python here. And let's assume that there
> are 100 Python users out there.
>
> When 50 of those are pro and 50 are contra, then Guido has a problem:)
> Whatever he decides will upset half the population.
>
> On the otherhand, when 1 is pro and 1 is contra and all the others don't
> care, then whatever he decides will be fine with the masses.
>
> In the first case we'd better help him and try to convince the other
> party that our view point* is the right one. In the other case we
> might as wel stop now and tell Guido to throw dices instead:) More
> seriously, when the pro's and contra's really are minority groups,
> then it's probably best not to add questionable syntactic sugar
> to the language.
Actually, the point of confusion was around whether or not there was a
need for an explicit 'do not care' vote (versus people simply choosing not
to vote). For most language changes the pro and con camps will _always_ be
minorities because the overwhelming majority of Python users probably
don't follow c.l.py closely, if at all.
-Dave
Carel Fellinger
...
> Why don't we just set up a web page with all the alternatives listed
> and checkboxes [-1] [-0] [+0] [+1] to click for each, and have cgi
> format a response page with a concise email mailto link with parameters encoding
> the vote info, so voters can just click the mailto link and have their local email
> client pop up with vote parameters already set up in subject and/or body, and
> all they have to do is send it.
>
> Valid return addresses could be checked if desired with automated return mail and
Yep, but not because people might vote twice, but to allow them to
_switch camps_ and revote. So remember the last vote, undo it, and
count the new vote.
--
groetjes, carel
Erik Max Francis
> Erik Max Francis <m...@alcyone.com> wrote:
>
> > Use parentheses for clarity, sure. _Require_ them, I don't see.
>
> Well, they're required for function calls. Surely you're not
> advocating
> making them optional in that case?
Oh come on, that is totally taken out of context. A better analogy
would be requiring them for the addition operator. There are times when
it's clearly useful to use parentheses for clarity. But that hardly
means they should be _required_.
x = a + b # illegal, should be (a + b)
x = (a + b)*c # fine
x = a + b*c # illegal, should be (a + b*c)
x = f(a + b) # illegal, should be f((a + b))
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Being in love for real / It ain't like a movie screen
\__/ India Arie
Bosskey.net: Aliens vs. Predator 2 / http://www.bosskey.net/avp2/
A personal guide to Aliens vs. Predator 2.
Erik Max Francis
> List comprehensions are required to be enclosed by punctuation pairs,
> even though it would be possible to parse them without those enclosing
> brackets (the presence of "for" after an expression being what would
> trigger the parser that this is a list comprehension).
But it makes a lot more sense for list comrpehensions, because 1. list
comprehensions are a very unique syntax and 2. the result of a list
comprehension _is_ a list, so it actually makes sense for it to be
enclosed in square brackets.
I'm not saying I'm frighteningly opposed to requiring parentheses, I'm
just saying I don't think it's necessary. In practice, I suspect I
would probably _use_ parentheses most of them I'd use a conditoinal
operator, just as I do when I use the ?: operator in C, C++, Java, or
(not that I write it anymore) Perl.
Erik Max Francis
> Erik, what do you plan to do ? I guess, you want to set up a web-page
> where people can vote the different proposals and see if there is a
> proposal with a majority consensus (majority in the "yes" party, I
> mean).
What? I have never been asked to do or been tasked with doing any
voting. I'd be happy to do it, but nobody (including me) has ever
suggested or claimed that I was going to be conducting any votes.
Erik Max Francis
[restoring attribution]
> Erik Max Francis wrote:
>
> > The "don't care" camp is _going_ to get underrepresented in any
> > vote, so
> > the question is what value or relevance should abstentions should
> > have
> > in the process.
>
> That isn't your decision. Otherwise we get government by 'the league
> of concerned citizens' (unless the ad-hoc-vigillante posse of
> unconcerned citizens tosses the aforementioned concerned citizens into
> the moat).
Golly gee, Laura, I don't ever recall stating that anything at all here
was _my_ decision, and in fact I explictly recall stating _several
times_ that I am more than happy with any voting process that everybody
agrees upon -- including all the potential "don't cares."
Erik Max Francis
> When 50 of those are pro and 50 are contra, then Guido has a problem:)
> Whatever he decides will upset half the population.
>
> On the otherhand, when 1 is pro and 1 is contra and all the others
> don't
> care, then whatever he decides will be fine with the masses.
The issue with this analysis is that you'll never know how large the
"don't care" camp is, almost by definition -- because if they don't care
then they won't vote.
Even if you hold a vote where you have a "yes," "no," and "abstain," and
the numbers come in as (say) 45%, 45%, and 10%, respectively, that
doesn't mean that 10% of the Python community at large doesn't care. It
could be that 99% of the Python community at large doesn't care, in
which case you're in the second scenario you depict above. The problem
is, just by including a "don't care" on the ballot, you'll never be able
to know that.
I'm perfectly happy with whatever voting process everybody is willing to
agree to (despite people repeatedly attempting to seem to want to put
words in my mouth). I'm just not seeing 1. the value of including such
a position on a ballot, or 2. what should be done with the "abstain"
figures.
By the way, Andrew Keonig's suggestion of a voting process where all
alternatives are listed, including "no change," the "don't cares" can
still indicate their position by submitting an empty ballot which
selects none of the options.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Do not seek death. Death will find you.
\__/ Dag Hammarskjold
Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
An Esperanto reference for English speakers.
Erik Max Francis
> Why don't we just set up a web page with all the alternatives listed
> and checkboxes [-1] [-0] [+0] [+1] to click for each, ...
The technical process of tallying the votes is really a minor issue;
it's easy to do, and quite frankly will not require much work even
building a voting system up from scratch (I would prefer an email-based
solution myself).
If I were to conduct the vote (note the clever use of the subjunctive
there), I'd simply set up a form that people could fill out and send to
a dedicated email address (which will go away when the vote is
complete), and then declare that the voting process starts when the form
is distributed and ends at some certain time (perhaps a week after
initially posted). All mail to the address would be gated to a mailbox,
then I'd use a Python (well, duh :-) script to process each mail
received and tally up the votes for all alternatives. Then the results
would be posted (with mangled email addresses so people don't get mad
:-) for everyone to see so that full accounting is possible. (The
script that tallies the votes would also be made available, too.)
I'm really inclined toward Andrew Koenig's suggestion for "approval
voting," where every conceivable option (including one for "I want no
change") is listed, and voters are encouraged to vote for as many or as
few as they wish. Not only does this reduce everything to one vote, but
it allows people to vote for multiple syntaxes they would accept, and
even allows for the ability to vote for things like, "Well, I really
don't want it, but if we _have_ to have it, I'd want _this_ syntax."
And, for the abstainers, you could simply not select any choices.
NOTE: At this point, no one has nominated me to do the vote, nor have I
been asked to do it, nor have I been tasked to do it by anyone with
authority. I'd be happy to do it (and would even offer to abstain from
the voting process myself if it helped put people at ease), but as of
right now I won't be involved in the actual votetaking in any way.
I'm slightly concerned with Aahz -- who it seems that people have
accepted as the votetaker even though it hasn't really been discussed --
being so hostile to the proposal from the very beginning. I'm more
concerned with the voting _process_ that he initially proposed, which
seemed (to me) very specifically designed to undermine the PEP passing
(he seemed to acknowledge my objections, but I didn't get a good
indication whether or not that actually changed the way he intended to
conduct the vote). I am, however, downright terrified of his threats of
voting against the proposal (votetaker or not) based on the actions of a
third party. Someone who is threatening to vote one way or the other
simply out of spite should _not_ be involved with a votetaking process
of any kind, in my (perhaps not so) humble opinion.
Erik Max Francis
> Michele Simionato wrote:
>
> > and I hate the next unavoidable step
> >
> > (try: X except: Y)
>
> "Unavoidable"? You've lost me.
He's attempting to invoke a "slippery slope" argument. I wonder if he's
aware that it's a logical fallacy.
Carel Fellinger
> On Tue, 11 Feb 2003, Carel Fellinger wrote:
> Actually, the point of confusion was around whether or not there was a
Yep, and I thought I'd explained why I want my "don't care" ticket:)
> to vote). For most language changes the pro and con camps will _always_ be
> minorities because the overwhelming majority of Python users probably
> don't follow c.l.py closely, if at all.
But I do follow c.l.py, I even try to follow this thread! And I do
care about the outcome, whatever it maybe. So why should my position
not be accounted for? God knows how many not-voters are dead against,
pro or indifferent to this language change. The only clue we get is
through voting. So why is it that pro/against votes of voters do count
although their might be many many more against/pro users not voting, and
indifferent voters not count at all?
Sure you'll agree that *if* pro/against groups both were real minorities
that then changing the language was out of the question. There are many
small groups lobying to get their pet in, and it would be silly to do so.
Unless it's a great idea, and fortunately that's still Guido to decide:)
If indefferent votes were counted too, we could tell how large or small
the pro/against groups are, *all* related to the number of people taking
their time to vote ofcourse.
--
groetjes, carel
Carel Fellinger
> Carel Fellinger wrote:
>
> > When 50 of those are pro and 50 are contra, then Guido has a problem:)
> > Whatever he decides will upset half the population.
> >
> > On the otherhand, when 1 is pro and 1 is contra and all the others
> > don't
> > care, then whatever he decides will be fine with the masses.
>
> The issue with this analysis is that you'll never know how large the
> "don't care" camp is, almost by definition -- because if they don't care
> then they won't vote.
Not so, as I tried to point out. There are those who *do* care, but
are indifferent to the outcome but for the fact that to warant any
addition the need should be substantial.
There are also those who are indifferent to the outcome but willing
to vote anyhow if they could only indicate their indifference.
Likely there are those in favour (or against) who don't care (enough)
to vote or who think the outcome is fixed so their vote won't help or
whatever.
Bottom line is that in any open voting, especially when the population
size is unknown, you don't know much :(
> Even if you hold a vote where you have a "yes," "no," and "abstain," and
> the numbers come in as (say) 45%, 45%, and 10%, respectively, that
> doesn't mean that 10% of the Python community at large doesn't care. It
> could be that 99% of the Python community at large doesn't care, in
> which case you're in the second scenario you depict above. The problem
> is, just by including a "don't care" on the ballot, you'll never be able
> to know that.
same holds for pro's/contra's. Just think about all those who don't read
meandering threads:)
> By the way, Andrew Keonig's suggestion of a voting process where all
> alternatives are listed, including "no change," the "don't cares" can
> still indicate their position by submitting an empty ballot which
> selects none of the options.
great!
--
groetjes, carel
David LeBlanc
> I'm really inclined toward Andrew Koenig's suggestion for "approval
> voting," where every conceivable option (including one for "I want no
> change") is listed, and voters are encouraged to vote for as many or as
> few as they wish. Not only does this reduce everything to one vote, but
> it allows people to vote for multiple syntaxes they would accept, and
> even allows for the ability to vote for things like, "Well, I really
> don't want it, but if we _have_ to have it, I'd want _this_ syntax."
> And, for the abstainers, you could simply not select any choices.
I'd be inclinded towards a 3 phase vote: initial to weed out candidates,
final to select "the" winner and third where Guido vetoes it ;)
<snip>
> I'm slightly concerned with Aahz -- who it seems that people have
> accepted as the votetaker even though it hasn't really been discussed --
> being so hostile to the proposal from the very beginning. I'm more
> concerned with the voting _process_ that he initially proposed, which
> seemed (to me) very specifically designed to undermine the PEP passing
> (he seemed to acknowledge my objections, but I didn't get a good
> indication whether or not that actually changed the way he intended to
> conduct the vote). I am, however, downright terrified of his threats of
> voting against the proposal (votetaker or not) based on the actions of a
> third party. Someone who is threatening to vote one way or the other
> simply out of spite should _not_ be involved with a votetaking process
> of any kind, in my (perhaps not so) humble opinion.
I have confidence in Aahz's integrity.
> --
> Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
> __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
> / \ Do not seek death. Death will find you.
> \__/ Dag Hammarskjold
> Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
> An Esperanto reference for English speakers.
> --
Dave LeBlanc
Seattle, WA USA
Erik Max Francis
> I have confidence in Aahz's integrity.
In one of these threads, he threatened to vote against the proposal
because I wasn't planning on listing his suggestion in my personal list
for my own edification (a form which the BDFL explicitly rejected in the
PEP, by the way). In other words, he was going to punish me for doing
something as an individual with no connection to the PEP or the voting
process by voting against the proposal.
I had reservations about his choice of voting processes (which I voiced
and which he acknowledged, but I don't know if he actually has any
intention of changing the process). But if he's going to threaten to
vote against a proposal based on the unrelated activities of someone
that is simply another voter, I have serious reservations about his
ethics. This is the _votetaker_ saying that he's going to do this.
That strikes me as extremely ungood.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The multitude of books is making us ignorant.
\__/ Voltaire
EmPy / http://www.alcyone.com/pyos/empy/
A templating system for Python.