[Tim]
>> Don't mix bools with ints with control structures,
[David Abrahams]
> That mixing was your suggestion, if I recall <.02 wink>
Of course: it solved your problem. That you went on to whine about it
isn't really my doing <wink>.
> ...
> 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.
Well, I invented that one, so I suppose it's possible. I've never actually
used it, though.
> 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.
Nobody has ever had to do stuff like that; fear of if/else is baffling to
me. I supported adding a ?: ternary workalike to Python anyway, and Guido
even implemented one, but gave up on it. Unfortunately, the reasons for
rejection were never recorded in a PEP.
> 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.
Yes. I don't mind them at all.
>> Na, do this:
>>
>> def bool(e):
>> return e and 'True' or 'False'
> Harrumph. The builtin doesn't create strings, but bools. I don't think
> doctest is going to ignore the quotes.
Damn, you're right. I'll patch doctest to special-case the snot out of
those specific strings <wink>. In the meantime,
def ibool(e):
return e and 1 or 0
# or "return operator.truth(e)"
will work across all Pythons forever, or back to 1.4 if you use
operator.truth to avoid offending yourself <wink>.
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