[Guido] > ... > Perhaps the current set implementation could be made faster by > limiting it somewhat more? The current API attempts to be fast *and* > flexible, but tends to favor correctness over speed where a trade-off > has to be made. But maybe that's a poor way of selling a new built-in > data type, and we would do better by having a truly fast > implementation that is more limited? It's easier to remove > limitations than to add them. I don't think you *can* get "fast" membership testing unless sets inherit the C-level dict.__contains__ directly. The time burden of going thru a Python __contains__ method can't be overcome. For all the rest, it's plenty fast enough for me. Note that the spambayes project uses sets freely, mostly for uniquification, but also for convenience in manipulating usually-small sets of email.Message objects. If you're going to *do* something with the set elements (which that project does), the time to uniquify the original sequence is likely (as it is in that project) trivial compared to the rest. For contexts requiring heavy-duty repeated membership testing, though, spambayes code still used a straight dict with values 1. premature-etc-ly y'rs - tim
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