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. No, please not. It's useful sometimes and doesn't hurt most times. > 1) The construct can be error-prone. When an error occurs it can be > invisible to the person who wrote it. I got bitten in published code > that had survived testing and code review: > > def real(self): > 'Return a vector with the real part of each input element' > # do not convert integer inputs to floats > return self.map(lambda z: type(z)==types.ComplexType and z.real or > z) I'm surprised you wrote that in the first place. The "and/or conditional" is one of the few occurences where one will carefully look for false values in the "and" part. > The code fails silently when z is (0+4i). It took a good while to trace > down a user reported error (when Matlab results disagreed with my matrix > module results) and determine that the real() method contained an error. > Even when traced down, I found it hard to see the error in the code. > Now that I know what to look for, it has not happened again, but I do > always have to stare hard at any "and/or" group to mentally verify each > case. [...] > P.S. Simplifying "and" and "or" may create a need to introduce a > conditional operator but that is a discussion for another day. Exactly. A conditional was turned down some time ago, for good reasons. Reinhold -- Mail address is perfectly valid!
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