> > 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
