[Python-Dev] PEP 218 (sets); moving set.py to Lib
Fri, 16 Aug 2002 18:32:15 -0400
> 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
> 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
> from set import Set, ImmutableSet
> - 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
> - 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>.