PEP-308 a "simplicity-first" alternative

[Christian Tismer]

Small, obvious correction:

Christian Tismer wrote:
> Terry Reedy wrote:
> 
>> "Bjorn Pettersen" <BPettersen at NAREX.com> wrote in message
>> news:mailman.1045095195.25260.python-list at python.org...
>>
>>> From: Bengt Richter [mailto:bokr at oz.net]
>>>
>>>> I think I have an answer:
>>>>    result = cond and {true_value} or false_value
>>
>>
>>
>>> Yes, we got you the first three times <wink>. Your proposal
>>> 1. Doesn't give any indication that the expression is
>>>   a selection (i.e. the same as x and y or b).
>>
>>
>>
>> Given that 'and' and 'or' are best described as conditional selection
>> operators (explaining this is another post not yet written), it is
>> straightforward that together they form a conditional selection
>> expression.
> 
> 
> I think I'm posting evolving messages about the
> same thing, but I more and more come to an insight:
> 
> 'and' and 'or' are logical selection operators.
> They use the value of two objects to decide which
> one to carry on. Their visual appearance includes
> the logical operation on the arguments in a way,
> which is the reason for their names.
> 
> If we now modify the true_value to become true all
> the time, then this is an abuse of the and operator,
> since it is no longer doing what it says, it is only
> carrying the right value's wrapper if the left value
> is true.

is not true. Por favor.

> This is a complete abuse of the language, and we should
> refuse to create work-arounds for it to make it work.
> 
> "x and y or z" as a spell of "if x then y else z"
> is known to be wrong. But perfectly valid, if it is really
> meant in its logical sense (what it seldom is).
> "x and {y} or z" is a correct heal of the wrong logic,
> but it abuses "and" and its reader, since "and" is not
> intended to do a left test only. Being used like that,
> "and" is the wrong name, since we are not intending to
> "and" anything, we want a "then".
> 
>  From a logical POV, the correct spelling of a logical
> "if a then b" construct would translate to "not a or b".
> But this works in Pascal, not in Python, since the truth
> operators have to carry their original operators.
> 
> I think this whole mixture of logic with objects is broken.
> 
> ciao - chris

Furthermore, by the presence of a real boolean type, we
should ask ourselves if "nad" and "or" shouldn't be
deprecated in their current meaning, towards being
"boolean only"?

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 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 provded 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 operator,
which I regard as a design flaw, but this is bearable.

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.

"and" and "or" do have a builtin perception of symmetry,
which is not 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 the truth value.

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 new code.

kind regards -- chris

p.s.: Please correct me positively, if I made a mistake at 4:00am

-- 
Christian Tismer             :^)   <mailto:tismer at 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/