PEP 308: "then" "else" for deprecating "and" "or" side effects
Christian Tismer
there has been some favor of my silly/simple a then b else c proposal.
Please let me elaborate a little on this, with respect
to the existing "and" and "or operators.
"and" and "or" are two-headed beasts:
At first glance, they pretend to be logical operators.
At second inspection, they do this logic by promoting
one of their operands.
This is not obviously bad, and it is consistant with the logic.
Due to the presence of a real boolean type, we
should ask ourselves if "and" and "or" shouldn't be
deprecated in their current meaning, towards being
"boolean only"?
I think it would be nicer if "and" and "or" would only
produce true or false. But this would break lots of code.
Therefore, I propose to keep them as they are, but to deprecate
using them to carry their operand values instead of a true truth
value.
This would be still allowed, but there are new, more explicit
operators, which should be used instead for new Python code:
The binary operators "then" and "else".
The ternary operator "then else".
For a clear definition, see the function
definitions below.
Example: Parameter cleanup.
Parameters are often massaged like this:
"or" case:
arg = arg or "Default"
The meaning of this phrase is:
"If the user has provided no argument value that is
true (non-empty or not 0 most of the time), then provide
some default value".
arg = arg then arg else "Default"
would be the verbose ternary replacement of this.
A short replacement would read better:
arg = arg else "Default"
which means "If arg is false, replace it by 'Default'".
"and" case:
arg = arg and 42
The meaning of this phrase is:
"If the user provided any argument that is true, use some
default value".
arg = arg then 42 else arg
would be the verbose replacement of this.
A short replacement would read better:
arg = arg then 42
Summary:
--------
"and" and "or" are behaving like logical operators.
They happen to do this by not providing a plain
truth value, but by promoting one of their operands.
"and" and "or" are valid operators, when used in a
logical context, only, meaning only to use the truth
value. They have the side effect of carrying an operand,
which I regard as a design flaw, but this is bearable
when used properly.
Using "and" and "or", when they are meant as "then" or "else"
should be deprectaed as bad style in the long term.
Almost all instances of "and" and "or" used to carry a value
can be replaced by "then" or "else" with ease, which makes the
resulting code much more readable without prior knowledge.
"and" and "or" do have a builtin perception of symmetry,
which is not related to the truth, and hard to explain to
newcomers.
Therefore, I propose to deprecate their use to promote
a value, and I propose to introduce "then" and "else"
as dual operators, together with the "then else" pair
as ternary operator, to be used in any context where
the inquiry should promote the right operand without
evaluating its truth value.
Definition:
-----------
Here is my "cure" to "and" and "or" with side-effects:
a then b
--------
is equivalent to
def then_proc(a, b):
if a:
return b
else:
return a
a else b
--------
is equivalent to
def else_proc(a, b):
if a:
return a
else:
return b
a then b else c
---------------
is equivalent to
def then_else_proc(a, b, c):
if a:
return b
else:
return c
"and" and "or" should be replaced by the above constructs,
in all contexts where "and" and "or" are not pure logical,
but are meant to propagate specific values, for all new code.
kind regards -- chris
p.s.: Please correct me positively, if I made a mistake at 4:15am
--
Christian Tismer :^) <mailto:tis...@tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
Erik Max Francis
> Due to the presence of a real boolean type, we
> should ask ourselves if "and" and "or" shouldn't be
> deprecated in their current meaning, towards being
> "boolean only"?
No, I don't think so. Their use is already too well-entrenched to want
to do something like this.
> "and" and "or" are behaving like logical operators.
> They happen to do this by not providing a plain
> truth value, but by promoting one of their operands.
They _are_ logical operators. They just do their logical by returning
one of the objects, rather than a strict Boolean. Other languages do
this, like Lisp; there's nothing inherently wrong with it. It's also
way too entrenched to change now. It's an example of a feature that I
don't often rely on, but even I, a champion of the Booleans PEP,
wouldn't think to change their behavior now.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The average dog is a nicer person than the average person.
\__/ Andrew A. Rooney
Python chess module / http://www.alcyone.com/pyos/chess/
A chess game adjudicator in Python.
François Pinard
> Dear community,
Nice way to salute! :-)
> there has been some favor of my silly/simple a then b else c proposal.
Not so long ago, I added a similar feature in an ad hoc language we created
for one project (French and specialised syntax, and written under pressure).
Strangely enough, it did not occur to me, before this morning, that there
was some relation with this long thread in the Python universe. :-)
If I translate the keywords of our syntax back to English, it gives:
a when b else c
with a chainable property not requiring parentheses:
a when b else c when d else ...
Our language is declarative (tinily functional) rather than imperative.
Yet, the above writings are not far from the original Guido suggestion.
I know I'm merely throwing yet another idea is this already overlong thread,
which I did not even attempt to read wholly. Maybe the above has been
suggested already. I've no intention whatsoever of pushing or defending it.
My opinion on PEP 308 is that, whatever is done or not done, the key to the
final decision should be the continued legibility of the Python language,
much more than the tiny bit of added functionality. It just happens that
for our little language, _not_ Python, the above has been received as quite
natural and legible by the non-programmers in the project -- they used that
language heavily for providing that knowledge base the project needed.
--
François Pinard http://www.iro.umontreal.ca/~pinard
Christian Tismer
> Christian Tismer wrote:
[and or]
>>"and" and "or" are behaving like logical operators.
>>They happen to do this by not providing a plain
>>truth value, but by promoting one of their operands.
>
>
> They _are_ logical operators. They just do their logical by returning
> one of the objects, rather than a strict Boolean. Other languages do
> this, like Lisp; there's nothing inherently wrong with it. It's also
> way too entrenched to change now. It's an example of a feature that I
> don't often rely on, but even I, a champion of the Booleans PEP,
> wouldn't think to change their behavior now.
That's fine with me. Note that I do not say that we
should change and and or (ignore my words about
future deprecation). Instead, we should not
abuse them in a way that has nothing to do with an
"and", like the "(a and [b] or [c])[0])" tricks
or the proposed {} escape. These are tricks to make
them behave differently.
I only propose to make these uses explicit
by using "then" and "else" instead.
Harvey Thomas
+1 to that
I think that to maintain readability we need to add a keyword. As when is surely less likely to be used as a variable name than yield, could we not treat it in the same way as the introduction of generators and for 2.4 one would need
from __future__ import ternary (or similar)
Harvey
_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service.
Carel Fellinger
...
> If I translate the keywords of our syntax back to English, it gives:
>
> a when b else c
>
> with a chainable property not requiring parentheses:
>
> a when b else c when d else ...
> My opinion on PEP 308 is that, whatever is done or not done, the key to the
> final decision should be the continued legibility of the Python language,
hear hear!
> much more than the tiny bit of added functionality. It just happens that
> for our little language, _not_ Python, the above has been received as quite
> natural and legible by the non-programmers in the project -- they used that
> language heavily for providing that knowledge base the project needed.
Does that little language of yours have an if-else statement? If so
could you wrap it up in parens and make it an if-else expression and
try it out on those non-programmers to see how they react to it? The
best way to do this would be to ask them in person, then it's easier
to see their reaction:)
I for one would find it very interesting whether my findings with my
twin daughters would prove more universal. They made it clear that
statements aren't expressions, hence making an expression out of a
statement by (merily) embracing it with parens might not be such a
smart move after all.
--
groetjes, carel
François Pinard
> Does that little language of yours have an if-else statement?
No, sorry. This is not an imperative language. The `... when ... else' is
the closest we have to an imperative `if else'.
--------------------
Let me chat a bit. We use the little language to describe fairly complex
relations of prerequisites for a selection and matching subsystem -- and no,
not at all, we are not in the sex industry! :-). The data gets compiled
into forms, which are then quite optimised for efficient evaluation.
The language, optimiser and evaluator have all been implemented in Python.
The legibility and cleanness of Python, also helped with our little
language, allowed such a clear expression of the problem that it was easy to
add new optimisations, unthought with the previous implementations in PL/I
or C. The current setup even compares favourably speed-wise, wiping out
most doubts and concerns of old-timers, here. The net effect is an
administrative decision that all projects are likely to be developed in
Python, from now on. Surely very pleasurable for me! :-)
djw
> most doubts and concerns of old-timers, here. The net effect is an
> administrative decision that all projects are likely to be developed in
> Python, from now on. Surely very pleasurable for me! :-)
>
;-)
/d/
Chermside, Michael
> I disagree with this. It sounds like the old 'sufficiency' argument -
> for example "you shouldn't have a subtract operator because addition
> and negation are sufficient".
And might I add, the persistent use of things like "cond and A or B" in
actual production Python code pretty much proves to me that the
existing language features are NOT sufficient.
[...]
> The fact that the arguments are lazy-evaluated is not, in my mind, a
> sufficient reason for claiming it isn't a function. Filter, map and
> reduce are also slightly unconventional (in that they take functions
> as parameters)
I find that statement rather puzzling. I personally write functions
all the time which take functions as parameters. It's not
"unconventional" at all!
[...]
> The idea of 'then' as an assertion that triggers backtracking on
> failure, and 'else' as an operator that can trap backtracking and
> provide an alternative is interesting, but probably just too obscure
I agree with you on this...
[...]
> If an
> operator-based form was to be used, I'd like a prefix to the syntax to
> tell me that a conditional expression is coming [...] leading to
> something like...
>
> either x if c1 else y if c2 else z
Hmmm... I don't find the "either" useful myself, but I can understand
why you prefer it. I'll have to mull that one over. For what it's worth
(one vote's worth, I suppose), I find
A if cond else B
highly readable, but somehow I'd prefer cond to come first, but
if cond: A else: B
seems to have too much punctuation for an expression. I think
cond then A else B
is probably unwise for the reasons you gave above. But I'm still
keeping an open mind on syntax.
-- Michael Chermside
Steven Taschuk
> Erik Max Francis wrote:
[... and & or ...]
> > They _are_ logical operators. They just do their logical by returning
> > one of the objects, rather than a strict Boolean. Other languages do
> > this, like Lisp; there's nothing inherently wrong with it. It's also
> > way too entrenched to change now. It's an example of a feature that I
> > don't often rely on, but even I, a champion of the Booleans PEP,
> > wouldn't think to change their behavior now.
>
> should change and and or (ignore my words about
> future deprecation). Instead, we should not
> abuse them in a way that has nothing to do with an
> "and", like the "(a and [b] or [c])[0])" tricks
How do you feel about reading
x /= y or 1
as "divide x by y, or by 1 if y sucks"? (I admit this example is
somewhat cryptic; my real question is whether you find this
reading of 'or' natural.)
--
Steven Taschuk | ,\
stas...@telusplanet.net | }<__`O=
| ' " Pleiosaur
Erik Max Francis
> If I translate the keywords of our syntax back to English, it gives:
>
> a when b else c
This doesn't look like a good counter to the `C then x else y' proposal,
since using `when' as the keyboard would imply the same ordering as the
original proposal:
x when C else y
as in, "Put a jacket on when it's old cold outside, otherwise [else]
where what you want." This form (with the condition in the middle) has
already been suggested -- in fact, it was one of the first alternatives
to the first if/else proposal brought up.
Using it to mean
C when x else y
definitely "reads" wrong in English; if you want this form, the `when'
should be a `then'.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ You win the victory when you yield to friends.
\__/ Sophocles
Bosskey.net: Quake III Arena / http://www.bosskey.net/q3a/
A personal guide to Quake III Arena.
Bengt Richter
>Dear community,
>
>there has been some favor of my silly/simple a then b else c proposal.
>
I kind of like it, but the "then" word is not ideal, IMO. To express
conditional evaluation (i.e., the short-circuit aspect), perhaps a
little change?
a condevals b else c
or maybe
a chooses b else c
or
a picks b else c
[... skipping other stuff for the moment ...]
Regards,
Bengt Richter
Sean Ross
And, while we're here, doesn't that sound nice?
wear = "jacket" when outside.iscold() else None
I like how the first option you want for 'wear' is seen first, and I like
how a 'when' expression could never
be confused with an 'if' statement, and I like how it reads as an english
sentence, and I like that a
"little language" designer already used it, and that developers using that
language are fine with it.
And, no, the condition is not out of order. And , no, it is not confusing.
And, if you can have 'then', why
not have 'when' instead... 'then', without 'if', makes me look for the 'if'
which english tells me should have
come before the <condition>.......ah, whatever......
tired-of-tilting-at-windmills-ly-y'rs...
Sean
"Erik Max Francis" <m...@alcyone.com> wrote in message
news:3E4D899C...@alcyone.com...
Erik Max Francis
> Actually, he does mean "x when C else y", not "C when x else y"...
Oh, okay, then I withdraw my objection. Note that `when' as an
alternative to `if' in the original `x if C else y' form was one of the
first additional alternative suggested.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Man is preceded by forest, followed by desert.
\__/ (graffiti written during French student revolt)
Computer science / http://www.alcyone.com/max/reference/compsci/
A computer science reference.
Sean Ross
"Erik Max Francis" <m...@alcyone.com> wrote in message
news:3E4DA919...@alcyone.com...
Christian Tismer
> Actually, he does mean "x when C else y", not "C when x else y"...
>
> And, while we're here, doesn't that sound nice?
>
> wear = "jacket" when outside.iscold() else None
It sounds absolutely nice, much nicer than an "if"
in the same position. Dunno why, probably just my
25 years of being used to "if" being in front.
Maybe sometimes a new keyword hurts much less than
imposing a new meaning to an existing one.
Could really live with that.
When is pretty - ly y'rs -- chris
Christian Tismer
> François Pinard wrote:
>
>
>>If I translate the keywords of our syntax back to English, it gives:
>>
>> a when b else c
>
>
> This doesn't look like a good counter to the `C then x else y' proposal,
> since using `when' as the keyboard would imply the same ordering as the
> original proposal:
>
> x when C else y
>
> as in, "Put a jacket on when it's old cold outside, otherwise [else]
> where what you want." This form (with the condition in the middle) has
> already been suggested -- in fact, it was one of the first alternatives
> to the first if/else proposal brought up.
>
> Using it to mean
>
> C when x else y
>
> definitely "reads" wrong in English; if you want this form, the `when'
> should be a `then'.
Who cares about that single character? :-))
Seriously, I don't care too much. It is all better than a
mis-placed "if" in my eyes.
And I really don't want to see an upcoming monstrous, embraced
(if a :then b :else c) construct to creep into the language, for
the small intended benefit. It should be as tiny as the outcome,
so even "a then b else c" isn't short enough. But there are limits...
all the best -- chris
Christian Tismer
> [Christian Tismer]
>
>
>>Dear community,
>
>
> Nice way to salute! :-)
as it was indented to be :-)
>>there has been some favor of my silly/simple a then b else c proposal.
>
>
> Not so long ago, I added a similar feature in an ad hoc language we created
> for one project (French and specialised syntax, and written under pressure).
> Strangely enough, it did not occur to me, before this morning, that there
> was some relation with this long thread in the Python universe. :-)
>
> If I translate the keywords of our syntax back to English, it gives:
>
> a when b else c
>
> with a chainable property not requiring parentheses:
>
> a when b else c when d else ...
>
> Our language is declarative (tinily functional) rather than imperative.
> Yet, the above writings are not far from the original Guido suggestion.
Well, the difference is of course quite big to me.
a when b else c when d else ...
compared to
a if b else c if d else ...
looks much smoother.
I also could imagine "where":
a where b else c where d else ...
All in favor over re-using a strong "if".
"if" is used to be too much right-orientated...
more-of-this -- chris
Christian Tismer
> On Fri, 14 Feb 2003 04:17:17 +0100, Christian Tismer <tis...@tismer.com> wrote:
>
>
>>Dear community,
>>
>>there has been some favor of my silly/simple a then b else c proposal.
>>
>
> I kind of like it, but the "then" word is not ideal, IMO. To express
> conditional evaluation (i.e., the short-circuit aspect), perhaps a
> little change?
>
> a condevals b else c
>
> or maybe
>
> a chooses b else c
>
> or
> a picks b else c
You are technically right.
But that "when" approach took me like a charm...
I have argued that "then" and "when" just make
a difference of a single letter. This was completely
crappy, since "when" replaces "if", not "then".
Isn't that just elegant? Elegance is a very
high level of Pythoniciy, rarely reached.
I really, really like it.
I now realize that I wasn't so unhappy with the order
of constructs, but of the misplaced "if", literally.
"when" is much less of a problem to me.
Think it over - ly y'rs -- chris
Bengt Richter
[...]
>And I really don't want to see an upcoming monstrous, embraced
>(if a :then b :else c) construct to creep into the language, for
>the small intended benefit. It should be as tiny as the outcome,
>so even "a then b else c" isn't short enough. But there are limits...
x vs y per C
well, ok, maybe not short enough ...
x vs y by C
after-beating-your-head-against-the-wall-any-letup-feels-good 'ly
Regards,
Bengt Richter
Michele Simionato
> Sean Ross wrote:
>
> > Actually, he does mean "x when C else y", not "C when x else y"...
>
> Oh, okay, then I withdraw my objection. Note that `when' as an
> alternative to `if' in the original `x if C else y' form was one of the
> first additional alternative suggested.
Yeah, and I think Sean was the first one who proposed it,
whereas I was one of the first supporters. Unfortunately,
it seems that most of the people don't like the order,
that's why now I am supporting my second choice,
"C then x else y", but still I think
"x when C else y" was better...
Michele
Erik Max Francis
> Yeah, and I think Sean was the first one who proposed it,
> whereas I was one of the first supporters.
Ah, fair enough. I've been carefully recording the propositions, but
not who suggested them (mostly because many of the forms are suggested
independently and so proper and fair credit can be problematic). If
Sean was indeed the one that suggested the when/else syntax alternate to
the initial if/else proposition, then all I've said is redundant and I
hereby retract it :-).
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Suffering is a journey which has an end.
\__/ Matthew Fox
Polly Wanna Cracka? / http://www.pollywannacracka.com/
The Internet resource for interracial relationships.
Mike Orr
not going to go away, because it's genuinely useful and allows one to
eliminate an entire if-block, the way a list comprehension eliminates
an entire for-block. Rejected or not, the tertieary operator will
continue to be a FAQ, so we may as well put it in the language now so
the issue will go away. That's what we did for '+=' and string
methods, which were rejected for years for pedantic reasons (+= as
unnecessary, string methods because "immutable objects don't have
methods"). Python has always been great in adding, not every feature,
but a few well-chosen features that have wide applicability. The
tertiary operator would be a good complement. (Sets and dict
comprehensions are two others; fortunately, sets are already here. :)
Christian Tismer <tis...@tismer.com> wrote in message news:<mailman.104519273...@python.org>...
> "and" and "or" are two-headed beasts:
> At first glance, they pretend to be logical operators.
> At second inspection, they do this logic by promoting
> one of their operands.
... which leads to the frustrating situation that they are "almost" a
tetiary operator but with a sneaky little gotcha.
result = a and b or c
# Whoops, 'b' is false. My result is wrong!
The fact that people try to use 'and ... or' so broadly for this shows
that something is missing. Only one little tweak is needed: an
alternative construct that faithfully returns 'b' if 'b' is false.
> Due to the presence of a real boolean type, we
> should ask ourselves if "and" and "or" shouldn't be
> deprecated in their current meaning, towards being
> "boolean only"?
> I think it would be nicer if "and" and "or" would only
> produce true or false. But this would break lots of code.
'and' and 'or' are fine as they are.
result = replyVar or DEFAULT
# I want DEFAULT if replyVar is '', 0 or None. What's wrong
# with that? If it ain't broke, don't fix it.
result = conditionA and conditionB
# A true boolean. Who cares what exactly 'result' is as long as
# it works properly in an 'if' statement. One can always use
# bool(result) if one really wants 'True'.
Now, on to syntaxes. I like these:
1) result = b if a else c
# Advantage: parallel to list comprehension syntax.
2) result = a ? b : c
# Similar to C/Perl/PHP. This is arguably more readable
# than (1).
3) result = a ?? b || c
# Good visual separation.
# Disadvantage: irritating to C/Perl programmers, for
# whom these operators have an entirely different meaning.
4) result = a then b else c
I don't like these:
A) result = if a then b else c
# Too polymorphic. Let's avoid expressions that "almost" look
# like statements, for the same reason '=' is not allowed in
# expressions.
B) result = if (a) then (b) else (c)
# This would be the only time Python requires '()' except for
# 1-tuples.
Terry Reedy
"Mike Orr" <m...@oz.net> wrote in message
news:a66bffb1.0302...@posting.google.com...
> The fact that people try to use 'and ... or' so broadly for this
shows
> that something is missing. Only one little tweak is needed: an
> alternative construct that faithfully returns 'b' if 'b' is false.
(not a or b) and c
But I would also like to have one syntax that covers all cases.
Terry J. Reedy
Jp Calderone
> The tertiary operator is one of those long-requested features that's
> not going to go away, because it's genuinely useful and allows one to
> eliminate an entire if-block, the way a list comprehension eliminates
> an entire for-block. Rejected or not, the tertieary operator will
> continue to be a FAQ, so we may as well put it in the language now so
> the issue will go away. That's what we did for '+=' and string
> methods, which were rejected for years for pedantic reasons (+= as
> unnecessary, string methods because "immutable objects don't have
> methods"). Python has always been great in adding, not every feature,
> but a few well-chosen features that have wide applicability. The
> tertiary operator would be a good complement. (Sets and dict
> comprehensions are two others; fortunately, sets are already here. :)
I disagree. Programmers are not, by and large, language developers. To
say that simply because many people ask for a feature, that feature is
desirable is to completely discard the idea that people who have experience
designing and implementing languages might have a better understanding of
the issues involved.
It is like saying that a race car driver is qualified to design a car.
Are they better qualified than the average joe? Probably. Are they as
qualified as an engineer at GM? Unlikely.
If there are good reasons to add a ternary operator, and people make them
well, then it should be added. If the only reason is that a lot of people
shout really loudly that they want it, then this is not a compelling reason,
and the operator should not be added.
Just so you don't think I'm against every language extension, I love
string methods >:) (Augmented assignment was a big mistake, though!)
Jp
--
up 10 days, 2:28, 5 users, load average: 0.20, 0.11, 0.09
Erik Max Francis
> It is like saying that a race car driver is qualified to design a
> car.
> Are they better qualified than the average joe? Probably. Are they
> as
> qualified as an engineer at GM? Unlikely.
(Actually, modern race car drivers are really quite involved with car
design these days.)
Even if we take your example at face value, it's still missing a key
point: Just because a feature is frequently requested does _not_ mean
that it's a bad feature.
If, using your analogy, the race car driver is not an expert and wants
something done a certain way, that doesn't _necessarily_ mean he's
wrong. He could be right. (And, actually, modern race car drivers are
really quite involved with car design these days.)
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Bring me men / Bring me men who'll turn the page
\__/ Lamya
Erik Max Francis' bookmarks / http://www.alcyone.com/max/links/
A highly categorized list of Web links.
Jp Calderone
> Jp Calderone wrote:
>
> > It is like saying that a race car driver is qualified to design a
> > car.
> > Are they better qualified than the average joe? Probably. Are they
> > as
> > qualified as an engineer at GM? Unlikely.
>
> (Actually, modern race car drivers are really quite involved with car
> design these days.)
>
> Even if we take your example at face value, it's still missing a key
> point: Just because a feature is frequently requested does _not_ mean
> that it's a bad feature.
>
> If, using your analogy, the race car driver is not an expert and wants
> something done a certain way, that doesn't _necessarily_ mean he's
> wrong. He could be right. (And, actually, modern race car drivers are
> really quite involved with car design these days.)
I did not mean to prove that the ternary operator is a bad feature because
many people request it, only that it should not be added for -only- that
reason (which was what was suggested in the post I responded to). Other
support is necessary.
Jp
--
http://catandgirl.com/view.cgi?44
--
up 10 days, 4:28, 4 users, load average: 0.08, 0.07, 0.03
Tim Peters
> The tertiary operator is one of those long-requested features that's
> not going to go away, because it's genuinely useful and allows one to
> eliminate an entire if-block, the way a list comprehension eliminates
> an entire for-block. Rejected or not, the tertieary operator will
> continue to be a FAQ, so we may as well put it in the language now so
> the issue will go away. That's what we did for '+=' and string
> methods, which were rejected for years for pedantic reasons (+= as
> unnecessary, string methods because "immutable objects don't have
> methods").
This is a bit of revisionist history a bot can't let pass. Guido was on
record in favor of += in the first year of Python's life, but didn't give it
high priority, and as the years flew by it became clear there were thorny
design issues that needed to be worked out first. Implementation proceeded
swiftly after they were. The ascendance of NumPy pushed it along in a big
way (doing "a = a + b" in a memory-efficient way when a and b are
multi-megabytes arrays isn't easy without fiddling the byte code; but it's
straightforward for an __iadd__ method).
String methods were even more of a "sure, but who's got time for it?" thing.
JPython and the introduction of Unicode strings tipped the balance toward
action on that one.
Nothing similar has happened to push conditional expressions to the fore.
When Guido implemented them two years ago (I've given a reference to the
patch on SourceForge several times), he ended up rejecting his patch because
he didn't find good uses in the standard library. I went through a similar
exercise recently, and found only a few -- but then I'm quite accustomed to
seeing dirt-simple uses of and/or by now, like
ok and "yes" or "no"
and wouldn't bother to change such existing uses. You get used to it (which
isn't a ringing endorsement <wink>).
> Python has always been great in adding, not every feature,
> but a few well-chosen features that have wide applicability.
The perceived lack of which (wide applicability) being why Guido rejected
his implementation of conditionals last time around. I can't say I've seen
many compelling use cases in this incarnation of the beast (and, no, min and
max aren't compelling -- although they would be if they weren't built in
already -- if "functions like that" were common, I'd expect to see some
examples other than min and max <wink>).
Terry Reedy
"Tim Peters" <tim...@comcast.net> wrote in message
news:mailman.1045800478...@python.org...
> [Mike Orr]
> > Python has always been great in adding, not every feature,
> > but a few well-chosen features that have wide applicability.
>
> The perceived lack of which (wide applicability) being why Guido
rejected
> his implementation of conditionals last time around. I can't say
I've seen
> many compelling use cases in this incarnation of the beast (and, no,
min and
> max aren't compelling -- although they would be if they weren't
built in
> already -- if "functions like that" were common, I'd expect to see
some
> examples other than min and max <wink>).
If Python did all looping by recursion, there would be many more
possible uses (though no more necessity) for a ternary conditional:
def fact(n): return n and n*fact(n-1) or 1
# needs a negative arg guard
def sum(seq): return (len(seq) or 0) and seq(-1) + sum(:-1)
# works better with head/tail linked list so no copying of tail
But Python does have for, while, map, filter, reduce, file.readlines,
(new) itertools, etc. in addition to min and max.
Terry J. Reedy
Michael Hudson
> [Mike Orr]
> > The tertiary operator is one of those long-requested features that's
> > not going to go away, because it's genuinely useful and allows one to
> > eliminate an entire if-block, the way a list comprehension eliminates
> > an entire for-block. Rejected or not, the tertieary operator will
> > continue to be a FAQ, so we may as well put it in the language now so
> > the issue will go away. That's what we did for '+=' and string
> > methods, which were rejected for years for pedantic reasons (+= as
> > unnecessary, string methods because "immutable objects don't have
> > methods").
>
> This is a bit of revisionist history a bot can't let pass.
Two can play at that game :-)
> Guido was on record in favor of += in the first year of Python's
> life, but didn't give it high priority, and as the years flew by it
> became clear there were thorny design issues that needed to be
> worked out first. Implementation proceeded swiftly after they were.
As I recall it, I got tired of the debates and implemented += and
friends as pure syntactic sugar. Then Thomas Wouters decided to do
what was necessary to get them into the core (i.e. resolving the
issues you talk about) and did it. So implementation and
issue-resolution went almost hand in hand.
Basically what got augmented assignment into the core was a couple of
people getting tired of the gassing about it and writing some code
(it's possible this tactic is a bit too effective).
I'm not sure that would help the current debate much, given that
conditional exps hafve been implemented at least once already...
Cheers,
M.
--
SPIDER: 'Scuse me. [scuttles off]
ZAPHOD: One huge spider.
FORD: Polite though.
-- The Hitch-Hikers Guide to the Galaxy, Episode 11
Neil Schemenauer
> Basically what got augmented assignment into the core was a couple of
> people getting tired of the gassing about it and writing some code
> (it's possible this tactic is a bit too effective).
Ditto for generators. In retrospect, I don't find them as useful
as I thought they would be. I guess some people like them.
Neil
Tim Peters
> Basically what got augmented assignment into the core was a couple of
> people getting tired of the gassing about it and writing some code
> (it's possible this tactic is a bit too effective).
It's getting less so over time, starting with bytecodehacks <wink>.
[Neil Schemenauer]
> Ditto for generators. In retrospect, I don't find them as useful
> as I thought they would be. I guess some people like them.
When they're the right solution, nothing else satisfies. If you haven't
looked lately, the spam filter you're using contains about 100 yield
statements (the tokenizer is one massive distributed generator, although
more-essential use of generators was made in the statistical testing
framework, to chew over tens of thousands of msgs in a memory-efficient
way). I've found bread-and-butter uses like that so natural that I had to
think about whether I've ever used generators at all(!).
andrew cooke
haven't followed the discussion, so this might have been covered
(although searching google for tertiary and lazy on the group turned
up nothing).
if using a funcion like cond(a, b, c) doesn't work because of eager
evaluation of parameters, you might consider adding lazy evaluation to
python. i would guess the general consensus on this is something like
"lazy evaluation may be powerful in some cases, but we can get the
same functionality in other ways and we don't want to scare the
bejeezus out of newbies". to which i'd reluctantly agree. but it can
be so neat, and maybe someone smarter than me can find a super-elegant
syntax, "or something"...
cheers,
andrew
A. Lloyd Flanagan
> And, while we're here, doesn't that sound nice?
>
> wear = "jacket" when outside.iscold() else None
>
I'm convinced.
+1 to 'x when C else y'
As for the utility of this operator, I find myself all the time doing:
if C:
b = x
else:
b = y
and thinking, "gee, I could use a ternary operator here."
Michael Hudson
> i've just read the pep (it seems to be doing the rounds in blogs) and
> haven't followed the discussion, so this might have been covered
Given the thousands of posts on this topic, how could it not have
been?
> (although searching google for tertiary and lazy on the group turned
> up nothing).
"tertiary" is a new and creatively bad search term for this topic :-)
> if using a funcion like cond(a, b, c) doesn't work because of eager
> evaluation of parameters, you might consider adding lazy evaluation to
> python.
Two comments:
1) adding lazy evaluation to Python to get a conditional operator is
just plain bonkers
2) There's a reason for this table:
|no side effects| side effects |
---------------+---------------+---------------+
| ML(ish) | Python, C, |
strict | probably some | many others |
| others | |
---------------+---------------+---------------+
lazy | Haskell | <gaping void> |
---------------+---------------+---------------+
Cheers,
M.
--
same software, different verbosity settings (this one goes to
eleven) -- the effbot on the martellibot
sik0fewl
> "Sean Ross" <sr...@connectmail.carleton.ca> wrote in message news:<log3a.33806$Ww1.9...@news20.bellglobal.com>...
>
>>And, while we're here, doesn't that sound nice?
>>
>> wear = "jacket" when outside.iscold() else None
>>
>
>
> I'm convinced.
> +1 to 'x when C else y'
I like "case: (cond, iftrue, iffalse)". This could also be written as
"case:(cond, iftrue, iffalse)".
I never got any replies the first time I suggested this, so I'm sure
nobody else likes it :)
--
Ryan
andrew cooke
[...]
> be so neat, and maybe someone smarter than me can find a super-elegant
> syntax, "or something"...
someone did - see pep 312 http://www.python.org/peps/pep-0312.html
andrew
Erik Max Francis
> someone did - see pep 312 http://www.python.org/peps/pep-0312.html
It's not entirely clear what this gains us except the omission of the
keyword lambda. It shortens code that uses it, but does so with a
penalty of introducing more keyword-less, syntactic sugar. Is PEP 312
really a good idea?
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ It's soulful music. It doesn't necessarily sound like ... soul ...
\__/ Sade Adu
Official Omega page / http://www.alcyone.com/max/projects/omega/
The official distribution page for the popular Roguelike, Omega.
je...@compy.attbi.com
> andrew cooke wrote:
>
>> someone did - see pep 312 http://www.python.org/peps/pep-0312.html
>
> It's not entirely clear what this gains us except the omission of the
> keyword lambda. It shortens code that uses it, but does so with a
> penalty of introducing more keyword-less, syntactic sugar. Is PEP 312
> really a good idea?
It gains you your lazy ternary operator, and is *also* useful in other
circumstances. The "if" implementation is then merely a special case of
something else that is useful elsewhere.
Note, and I can't emphasize this enough, that **every** argument that can
be brought to bear against 312 applies equally to the ternary operator.
Newbie confusion, one more thing to learn, "what is it really good for?",
etc. I won't go so far as to claim that supporting the ternary operator
should imply some level of support for this, but it shouldn't be missed
that it's the exact same arguments against it. To wit:
> It's not entirely clear what the ternary gains us except the omission of
> a relatively short if-block. It shortens code that uses it, but does so
> with a penalty of introducing more (potentially keyword-less,)*
> syntactic sugar. Is PEP 308 really a good idea?
*: depending on the exact proposal chosen; I think those have mostly
fallen out of favor.
That read exactly the same as 308 criticisms, and is equally valid for the
same reasons.
I believe there are two importent differences between 308 and 312. One is
that lambda already exists, this is just a special-case respelling of it,
so technically, nothing new. (A ternary operator is new, as nothing
currently acts like that in Python; even _ and _ or _ is really two binary
operators strung together, each with an independent reason to exist.
Two, this is sufficiently more powerful then the ternary operator that it
might actually tip the balance in favor of adding it.
The 312 implementation of the ternary operator is even more concise in use
then many of the proposals. Plus there are obvious translations to
quaternary or n-ary operators:
def nary(cond, *args):
return args[int(cond)]()
print nary (2, :x + 1, :x / 2, :x * 3)
not that anybody will actually use that, but the point is that it can be
used to build many useful things in addition to the special-case ternary
operator, not to mention the many other times such things can be useful.
I think it's also worth pointing out that the fact that there is pretty
much one syntax that makes sense for this, whereas the ternary operator
has still only converged to what, three or four strong proposals at least
(and I'm being generous)? This inability to pick one firmly says
something, I think, and it says something about 312 as well.
To date this is the only thing I'd vote +1 on, as the only proposal to
actually *balance* power with the additional complication in the language,
instead of adding complication to the language for a piddling feature it's
done without for 10+ years. If we *must* have support for a lazy ternary
operator, this is the way to go.
(Side note: It'll be interesting to see how the vote goes; clearly those
against 308 have stopped talking, making it seem as if support is now
overwhelming. It's impossible to know whether those still talking about it
are in the minority, the rest of us having largely said our piece and
moved on... ;-) and equally impossible to tell if support has been
overwhelming from day one, so no accusations of bias, please ;-) )
Erik Max Francis
> It gains you your lazy ternary operator, and is *also* useful in other
> circumstances. The "if" implementation is then merely a special case
> of
> something else that is useful elsewhere.
Yes, but you already have exactly this functionality, with lambda: etc.
All this proposal suggests is making the `lambda' keyword optional for
zero-argument anonymous functions, or thunks. This makes code less
readable and more arcane, not more.
> Note, and I can't emphasize this enough, that **every** argument tha
> can
> be brought to bear against 312 applies equally to the ternary
> operator.
No, I don't agree with that at all. PEP 308 suggests the addition of a
concise short-circuiting conditional operator, where none is presently
available; getting the full functionality of a conditional operator with
presently available Python results in monstrosities like
(C and [x] or [y])[0]
or
(C and lambda: x or lambda: y)()
which defeat the whole purpose for wanting the operator in the first
place (conciseness _and_ readability). PEP 312 simply suggests a
shortcut for
lambda: x,
by making it legal to write it as
:x
This _is_ purely syntactic sugar, and just strips off perfectly readable
keywords to make things shorter rather than more readable. (One can
certainly make arguments whether or not they find the use of lambdas
acceptable one way or the other, but when you come across a lambda, you
sure as hell know what you've just stepped into.)
I really fail to see the advantage in removing the one keyword that sets
the code apart ("Watch out, there is a thunk here!")
> I believe there are two importent differences between 308 and 312. One
> is
> that lambda already exists, this is just a special-case respelling of
> it,
> so technically, nothing new.
And that's a really tremendously big difference, quite frankly.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ We're here to preserve democracy, not to practice it.
\__/ Capt. Frank Rasmey
CSBuddy / http://www.alcyone.com/pyos/csbuddy/
A Counter-Strike server log file monitor in Python.
je...@compy.attbi.com
> je...@compy.attbi.com wrote: (stuff with two >>'s)
> Yes, but you already have exactly this functionality, with lambda: etc.
Same for the ternary operator.
Again, every argument against PEP312 applies to PEP308; this time you
used "You can already do this with current syntax if you want.", which I
failed to mention specifically.
>> Note, and I can't emphasize this enough, that **every** argument tha can
>> be brought to bear against 312 applies equally to the ternary operator.
>
> No, I don't agree with that at all. PEP 308 suggests the addition of a
> concise short-circuiting conditional operator,
PEP 312 suggests the addition of a short-circuiting operator *in general*.
Also, I don't see how the subsequent stuff challenges my assertion that
every argument against 312 applies to 308. Again, "purely syntactic sugar"
applies equally strongly to X if C else Y and everything else; *none* of
this is new capability. It just reinforces my point.
> I really fail to see the advantage in removing the one keyword that sets
> the code apart ("Watch out, there is a thunk here!")
Brevity, since that's the whole point of 308. If it's so important it's
worth adding a new operator, it's importent enough to add something
actually flexible enough to be useful. If it's not a sufficient
justification for 312, it's even less of a justification for 308, which
doesn't even have the virtue of being powerful.
Erik Max Francis
> On Thu, 27 Feb 2003 20:10:23 -0800, Erik Max Francis wrote:
>
> > Yes, but you already have exactly this functionality, with lambda:
> > etc.
>
> Same for the ternary operator.
No, it's not the same. The functionality of a conditional operator is
possible in Python only with great awkwardness, defeating the purpose
for using a conditional operator in the first place. PEP 312 merely
seeks to shorten a previously existing syntax by exactly one keyword.
> PEP 312 suggests the addition of a short-circuiting operator *in
> general*.
It's not short circuiting in the sense of implicit lazy evaluation.
It's simply a shorthand for writing zero-argument lambdas.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Conversation is the enemy of good wine and food.
\__/ Alfred Hitchcock
Physics reference / http://www.alcyone.com/max/reference/physics/
A physics reference.
Paul Boddie
>
> No, it's not the same. The functionality of a conditional operator is
> possible in Python only with great awkwardness, defeating the purpose
> for using a conditional operator in the first place.
Yes, but the wider issue is: do we need a conditional operator at all?
It's not as if the conditional operator opens up completely new areas
of previously-impossible stuff - instead it just makes some things,
under certain specific circumstances, more convenient. The assumption
seems to have been that people can't do without such an operator, but
if the only tool in your toolbox is a hammer...
> PEP 312 merely seeks to shorten a previously existing syntax by exactly one
> keyword.
That's why it appears even more frivolous than PEP 308.
Paul
P.S. See also: http://www.python.org/search/hypermail/python-1993/0273.html
Is this "The Ternary Operator Tenth Anniversary Debate" or what?
Michael Hudson
> P.S. See also: http://www.python.org/search/hypermail/python-1993/0273.html
> Is this "The Ternary Operator Tenth Anniversary Debate" or what?
That's October '93; I *really* hope the debate doesn't drag on that
long...
Cheers,
M.
--
[Perl] combines all the worst aspects of C and Lisp: a billion
different sublanguages in one monolithic executable. It combines
the power of C with the readability of PostScript. -- Jamie Zawinski
Erik Max Francis
> Erik Max Francis <m...@alcyone.com> wrote:
>
> > PEP 312 merely seeks to shorten a previously existing syntax by
> > exactly one
> > keyword.
>
> That's why it appears even more frivolous than PEP 308.
I wouldn't disagree with that in the slightest. That was exactly what I
was expressing in my question about its validity.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ That it will never come again is what makes life so sweet.
\__/ Emily Dickinson
WebVal / http://www.alcyone.com/pyos/webval/
URL scanner, maintainer, and validator in Python.