PEP 308: "then" "else" for deprecating "and" "or" side effects
Dear community, 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:tismer@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/
On Thursday 13 February 2003 07:17 pm, Christian Tismer wrote:
Dear community,
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.
I read the following with interest, and started considering some implications. My conclusions follow at the end.
"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
The above defines two binary operators "then" and "else" and a ternary operator "then...else". The question which occurred to me is: Since the ternary operator is formed by what looks like two binary operators, can the action of the ternary operator be defined in terms of the actions of the two binary operators. In other words, does the expression: a then b else c # the ternary operator evaluate as either a then (b else c) # two binary operators or (a then b) else c # two binary operators The answer is *NO*, all three expressions evaluate to different results. More on that below. Now we are used to disambiguating expressions with multiple binary operators by considering the precedence and (left or right) associativity of the operators involved. That is (a-b-c) evaluates as (a-b)-c and (a+b*c) evaluates as a+(b*c). However, in this "then...else" expression, something which looks like (and could be legitimately parsed as) two binary operations, in fact cannot be disambiguated by either application of parentheses and must be treated as a ternary operator. That in itself is bad enough, but to be a complete definition of these operators, one must now define how, in a sequence of "then"s and "else's, the parser can tease out which form ternary "then...else" operators, and how those ternary "then...else" portions fit (precedence wise and associativity wise) with the other ternary "then...else"s and any remaining binary "then"s and "else"s. These rules, whatever thay may turn out to be, would probably be more complex than I'd like to see in Python. Here is a truth table for the three expressions. The table not only tells the truth value of the result, but shows, in parentheses, *which* term is returned to express that truth value. Note that the three columns R, S, and T all differ for at least some set if input values. a b c R S T --------------------------------- F F F F(c) F(a) F(c) F F T T(c) F(a) T(c) F T F F(c) F(a) F(c) F T T T(c) F(a) T(c) T F F F(b) F(c) F(c) T F T F(b) T(c) T(c) T T F T(b) T(b) T(b) T T T T(b) T(b) T(b) where R -> (a then b else c) S -> a then (b else c) T -> (a then b) else c Dr. Gary Herron gherron@islandtraining.com
Christian Tismer wrote:
Dear community,
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"?
You are forgetting a detail here: "and" as well as "or" are not implemented as operators. "&" and "|" are the boolean operators and these do return boolean values. Note that you can't do "true" | "false" and then get "true" as result. What you get is a TypeError. "and" and "or" are control structures which test for truth values and then branch accordingly, leaving the true result on the stack. Constructs misusing "and" and "or" for the sake of inlining if-then-else should be reserved for those who know what they're doing (and can live with the consequences). Everybody else should really stick to the explicit: # value = x ? a : b if x: value = a else: value = b This is clean, shows exactly what you're doing and doesn't hide the flow of control from the reader: value = a is only executed in case x is found true. In that case the value = b branch is never entered into. As a result, side-effects in the value = b branch do not take effect. -- The tendency to let inling features creep into the language makes me a little nervous. The simplicity of Python is losing big with each new way to put more information on one line. This can be compared to lossy compression of an image: you can still grasp the general picture, but the details become unsharp and distored. Complexity should be reserved to what you write, not how you write it. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 14 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 46 days left EuroPython 2003, Charleroi, Belgium: 130 days left
[Christian Tismer]
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
On Fri, Feb 14, 2003 at 09:34:27AM -0500, François Pinard wrote: ...
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
[Carel Fellinger]
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! :-) -- François Pinard http://www.iro.umontreal.ca/~pinard
François Pinard wrote:
[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 :^) <mailto:tismer@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/
On Fri, Feb 14, 2003 at 04:17:17AM +0100, Christian Tismer wrote:
arg = arg then 42 else "Default" arg = arg else "Default" arg = arg then 42
I feel the "then" above reads very funny; besides, as it isn't currently in python, it means a new keyword. Guido's proposal reads better, despite the funny ordering: arg = 42 if arg else "Default" If you have an idea of how to disambiguate it, then we could augment his with your binary ideas: arg = arg else "Default" arg = 42 if arg []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/
Lalo Martins wrote:
On Fri, Feb 14, 2003 at 04:17:17AM +0100, Christian Tismer wrote:
arg = arg then 42 else "Default" arg = arg else "Default" arg = arg then 42
I feel the "then" above reads very funny; besides, as it isn't currently in python, it means a new keyword. Guido's proposal reads better, despite the funny ordering:
arg = 42 if arg else "Default"
Please stay up-to-date. There is no such proposal any longer, although it reads much better to me than the latest version, which is complete overkill for me. "spraxelmaksel", if this is international for broken syntax.
If you have an idea of how to disambiguate it, then we could augment his with your binary ideas:
arg = arg else "Default" arg = 42 if arg
These reductions are always simple. It isn't about semantics at all. I simply refuse "a if b then c", for a simple reason: Way too many languages *have* some kind of spelled "if" which goes to the right. I don't want Python to use a keyword so much differently, then "a when b else c" looks pretty understandable to me, also if you were confrontated wiht 25+ languages, before. good night -- chris -- Christian Tismer :^) <mailto:tismer@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/
participants (6)
-
Carel Fellinger -
Christian Tismer -
Gary Herron -
Lalo Martins -
M.-A. Lemburg -
pinard＠iro.umontreal.ca