"Raymond Hettinger" <raymond.hettinger at verizon.net> writes:
> 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
> 2) When going back and forth between languages, it is easy to forget
> that only Python returns something other than a boolean.
As others point out, this isn't true.
> 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.
Huh? I thought this was for chained expressions? Things like 1 < x < 3.
I _like_ the explanation of 'and' and 'or' as they are now. They are
basically control flow constructs -- and have to be to get
short-circuiting to work -- and adding a coercion to bool at the end
seems to add complexity, not reduce it (on some levels, anyway).
> P.S. Simplifying "and" and "or" may create a need to introduce a
> conditional operator but that is a discussion for another day.
... which was in the past, I thought.
Cheers,
mwh
--
The meaning of "brunch" is as yet undefined.
-- Simon Booth, ucam.chat
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