Raymond Hettinger wrote: > 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. But then I would no longer be able to write foo = something or default_value which is one of my favourite Pythonisms! > 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'. No need to change the language because of this. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing at canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4