> Honestly, I assumed that > > x in iterable > > has a short-circuit implementation. Why doesn't it? It does. The ifilter() version is faster only because it doesn't have to continually return values to the 'in' iterator. The speedup is a small constant factor. > Let me just give you the reasons (in no particular order) for my > suggestion to include the `all' and `some/any' predicates: > > 1. Efficiency > Maybe I'm a bit naive here, but it seems to me that since these > predicates involve tight inner loops they offer good potential for > speedup, especially when used often and over many iterations. You're guessing incorrectly. The pure python versions use underlying itertools which loop at full C speed. You cannot beat the ifilter() version. > 2. Readabilty > If we offer universally-used predicates with succinct names which are > available as part of the "batteries included" then that increases > readabilty of code a lot. I put the code in the docs in a form so that people can cut and paste the function definitions it as needed. Then, they can use all(), any(), or no() to their heart's content. > 4. It's *not* trivial! > Contrary to what you imply it's not trivial for everybody to just write > efficient and well designed predicates with well-chosen names. This > discussion is the proof. :-) Cut and paste is your friend. Raymond
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