[Guido] > ... > Some minor open questions: > > - The set constructors have an optional second argument, sort_repr, > defaulting to False, which decides whether the elements are sorted > when str() or repr() is taken. I'm not sure if there would be > negative consequences of removing this argument and always sorting > the string representation. I'd rather you left this alone. Being sortable is a much stronger requirement on set elements than just supporting __hash__ and __eq__, and, e.g., it would suck if I could create a set of complex numbers but couldn't print it(!). > It would simplify the interface and make the output nicer (since > usually you don't think about setting this argument until it's too > late). I don't think that the extra cost of sorting the list of > elements will be a burden in practice, since normally one would only > print small sets (if a set has thousands of elements, printing it > isn't very user friendly). I think you could (and should <wink>) get 95% of the benefit here by changing the sort_repr default to True. I'm happy to say False when I know I've got unsortable keys. > - I'd like to change the module name from set.py to sets.py. Somehow > it makes more sense to write > > from sets import Set, ImmutableSet > > than > > from set import Set, ImmutableSet Cool. > - I'm aware that this set implementation is not the be-all and end-all > of sets. That's OK -- there is no such set implementation in existence. This one covers all simple uses, and many advanced uses -- go for it! > I've seen a set implementation written in C, but I was not very > impressed -- it was a massive copy-paste-edit job done on the > dict implementation, and we don't need such code duplication. Ditto (& I've said so before about what was most likely the same implementation). > ... > - Like other concrete types in Python, these Set classes aren't really > designed to mix well with other set implementations. For example, > sets of small cardinal numbers may be represented efficiently by > long ints, but the union method currently requires that the other > argument uses the same implementation. I'm not sure whether this > will eventually require changing. We could rehabilitate __coerce__ in a hypergeneralized form <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