[Python-Dev] PEP 218 (sets); moving set.py to Lib

[Tim Peters]

[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>.