RetroSearch Browse

Tue Sep 20 06:57:17 CEST 2005 · https://mail.python.org/pipermail/python-dev/2005-September/056529.html

> > 3) Even when it isn't being used, the possibility of non-boolean
return
> > value complicates the bytecode and parser.  To allow for "and/or",
the
> > conditional opcodes leave the tested value on the stack.  In most
cases
> > both branches go directly to a POP_TOP instruction.  Since the
POP_TOP
> > shouldn't be executed twice, the body of the positive branch has to
> > close with a jump over the other branch even when it is empty.
> 
> The solution to that is for the normal conditional opcodes
> to pop the stack, and to introduce separate bytecodes for
> implementing 'and' and 'or'. 

You're right.  The bytecode code be fixed-up right now with no change to
the language :-)

That leaves error reduction and clarity as the main motivations for
changing 'and' and 'or' to act like '&&' and '||' and for introducing a
conditional operator to handle everyone's favorite use cases.

Raymond

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-September/056529.html below:

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