[Python-ideas] Break the dominance of boolean values in boolean context

Lukas Lueg lukas.lueg at googlemail.com
Tue Sep 13 16:01:29 CEST 2011

> I think that's a pretty good explanation for why PEP 335 hasn't been
> pushed too hard - there's a lot of value in having not/and/or behave
> more like control flow structures rather than ordinary operations. PEP
> 335 does show that it's theoretically possible to make them behave
> more like operators, but that doesn't make it a good idea.

The question is if we want to treat bools more special than any other
type. Right now bools are the only place where this is done. Do we
really want to specialize the language in order to favour control flow
in the implementation? Forever? That's a bold statement.

> To be honest, I don't think anyone would cry too much if you decided
> to explicitly reject it on the basis of continuing to allow control
> flow optimisations for code involving not/and/or. While CPython
> doesn't do it, I believe there *are* control flow transformations that
> the current semantics permit that PEP 335 would disallow, such as
> automatically applying De Morgan's Law (I don't actually have a use
> case for doing that, I'm just mentioning it as a consequence of the
> semantics change proposed by the PEP).

Performance is always an argument. Python as a language, and most
especially CPython itself, has a history of favouring design over
application; the same should be true for bools. Concerning De Morgan's
Law, I think in Python this should be treated as a convention in the
implementation, not a rule of the language. After all, we also have
[1,2,3] + [4,5,6] = [1,2,3,4,5,6] not by rule but by simple reasoning.
Also: If an object does not override a certain boolean operation, the
compiler can still take advantage of optimisation. Progress on the AST
may pave the road for that.

More information about the Python-ideas mailing list