> [snip] > > no hope that this will ever complete in finite time, but does that > > mean it shouldn't start? I could write 1L<<e and avoid the issue, but > > then I'd be paying for long ops that I'll only ever need in a case > > that's only of theoretical importance. > > How about lazy sets? E.g. a CartesianProduct could delegate to its two > underlying (concrete) sets when checking for membership, and a > PowerSet could perform individual member cheks for each element in a > given subset... Etc. Have you got a use case for membership tests of a cartesian product? > I guess this might be too specific for the library -- subclassing > ImmutableSet and overriding the accessors shouldn't be too hard... > > (The nice thing about including it in the library is that you could > produce these things as results from operations on Set and > ImmutableSet, e.g. 2**some_set could give a power set or whatever...) Use case? --Guido van Rossum (home page: http://www.python.org/~guido/)
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