[Python-Dev] "and" and "or" operators in Py3.0

François Pinard pinard at iro.umontreal.ca
Tue Sep 20 02:27:23 CEST 2005

[Raymond Hettinger]

> I propose that in Py3.0, the "and" and "or" operators be simplified to
> always return a Boolean value instead of returning the last evaluated
> argument.

> 1) The construct can be error-prone.  When an error occurs it can be
> invisible to the person who wrote it.  I got bitten in published code
> that had survived testing and code review:

>   def real(self):
>     'Return a vector with the real part of each input element'
>     # do not convert integer inputs to floats
>     return self.map(lambda z: type(z)==types.ComplexType and z.real or z)

The real problem, above, is the starve for using `lambda'.

The abuse of `and' and `or' is a mere consequence of this.  Remove
`lambda' from Python, and most reasonable people would spontaneously
write more legible code instead.  I do not perceive Python as designed
to prevent unreasonable people from "outclevering" themselves.

> 2) When going back and forth between languages, it is easy to forget
> that only Python returns something other than a boolean.

C, C++, Lisp, and shells do the same as Python.  Or maybe more correctly,
Python borrowed short-circuiting booleans from other languages.

> 3) Even when it isn't being used, the possibility of non-boolean
> return value complicates the bytecode and parser. [...] P.S.
> Simplifying "and" and "or" may create a need to introduce a
> conditional operator but that is a discussion for another day.

If removed, to be re-introduced differently, the bytecode and parser
would not have gained simplicity overall.

> Executive summary.  Returning only Booleans reduces errors, makes
> the code easier to review, follows other language norms, and
> simplifies/speeds-up the generated code.

The summary reduces to: "Returning only Booleans would speed-up the
generated code, once in a while."

Now, could we evaluate that speed up on the average code, like on the
Python library say?  It might not be worth the change...

François Pinard   http://pinard.progiciels-bpi.ca

More information about the Python-Dev mailing list