[Python-Dev] PEP 308: "then" "else" for deprecating "and" "or" side effects

Christian Tismer tismer@tismer.com
Fri, 14 Feb 2003 04:17:17 +0100


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/