----- Original Message ----- From: "Tim Peters" <tim.one@comcast.net> > It has much more to do with expectations for what "and" and "or" do. Note > that they're not "operators" in Python, they're control structures, and > cannot be overridden. Yes, I realize what's actually going on (and/or are Lisp-y), but as I said, it rubs my expectations for expressions with bool the wrong way. > Don't mix bools with ints with control structures, That mixing was your suggestion, if I recall <.02 wink> > and you won't get surprised; "False or 0" returning 0 in Python is no more > surprising than that > > if False: > x = False > else: > x = 0 > > sets x to 0, and *oodles* of code relies on that equivalence. I think you were the one who taught me the wonderful (x and [y] or [z])[0] trick, so yes, I'm aware of that. On the other hand (I hope I'm a flame-retard now), people shouldn't have to do stuff like that, especially in a world with bool. In any case, it seems to me that it's been correctly noted that you /will/ see these mixtures for quite some time to come, because of legacy code. > > I think I'd better just write my own assertion routine, as Guido > > suggested. I don't like non-obvious language constructs for something so > > simple (I'd mention ?: here but I don't need the bruises). > > Na, do this: > > def bool(e): > return e and 'True' or 'False' > > Then wrap your true/false expressions in bool() calls. All assuming > x-version invariance is important to you. When versions of Python before > 2.3 become uninteresting, get rid of the bool() function (and so unmask the > builtin of the same name). Harrumph. The builtin doesn't create strings, but bools. I don't think doctest is going to ignore the quotes. -Dave
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