[Python-Dev] I think my set module is ready for prime time; comments?

Tim Peters tim.one@home.com
Thu, 25 Jan 2001 02:29:19 -0500


[Guido]
> ...
> It's no big deal if the Vaults contain three or more set modules --
> perfect even, people can choose the best one for their purpose.

They really can't, not realistically, unless all the modules in question
conform to the same interface (which users can't control), and users
restrict themselves to methods defined only in the interface (which users
can control).  The problem is that "their purpose" changes over time, and in
some cases the effects of representation on performance simply can't be
out-guessed in advance of actual measurement.  If people need to change any
more than just the import statement, *then* a single implementation has to
be all things to all people.

I hate to say this (bet <wink>?), but I suspect the fact that Python's basic
types are all builtin and not classes has kept us from fully appreciating
the class-based "1 interface, N implementations" approach that C++ and Java
hackers are having so much fun with.  They're not all that easy to find, but
people who have climbed the steep STL learning curve often end up in the
same ecstatic trance I used to see only among fellow Pythoneers.

> But in the core, there's only room for one set type or module.

I don't like the conclusion:  it implies there's no room in the core for
more than one implementation of anything, yet one-size-fits-all doesn't.  I
have no problem with the idea that there's only room for one Set *interface*
in the core.  Then you only need Pronounce on a reasonable set of abstract
operations, and leave the implementation tradeoffs to be made by different
people in different ways (I've really got no use for Eric's list-based sets;
he's really got no use for my sets-of-sets).

That said, if there can be at most one, and must be at least one, a
hashtable based set is the best compromise there is, and mutable objects as
elements should not be supported (they add great implementation complexity
for the benefit of relatively few applications).

jeremy's-set-class-couldn't-be-accused-of-overkill<wink>-ly y'rs  - tim