[Brian Quinlan] > [Bunch of arguments combined - and then snipped :-)] > > For people who want to do integer arithmetic using Booleans, would > calling the int() built-in be too much of a burden? > > Samuele's example would be written as: > > def count_visible(win_list): > c = 0 > for win in win_list: > c+= int(win.visible) > return c > > That actually seems clearer to me and it fits with Pythons strongly > typed nature. > >From just the snippet I would wonder whether win.visible is one of the strings '0' or '1' or a float or a boolean. If *I* was about to separate bool from int (but for that I would need to be conviced about the errors I'm going to avoid with that), both int(False) and int(True) would fail - I mean - their result is as much intuitive as summing booleans directly <wink>. E.g. in VisualWorks (a Smalltalk) "true asInteger" happily fails. Also in Scheme and Common Lisp there is no truthvalue -> 0/1 conversion as a to-integer conversion. So I would introduce a specific built-in for that conversion (maybe chi() <wink>). I'm quite serious, int is too much polymorphic if your point is not to mix things with booleans. regards.
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