[Python-Dev] re: Using lists as sets

[gvwilson@nevex.com]

[After discussion with Ping, and weekend thought]

I would like to vote against using lists as sets:

1. It blurs Python's categorization of containers.  The rest of the world
   thinks of sets as unordered, associative, and binary-valued (a term I
   just made up to mean "containing 0 or 1 instance of X").  Lists, on the
   other hand, are ordered, positionally-indexed, and multi-valued.
   While a list is always a legal queue or stack (although lists permit
   state transitions that are illegal for queues or stacks), most lists
   are not legal sets.

2. Python has, in dictionaries, a much more logical starting point for
   sets.  A set is exactly a dictionary whose keys matter, and whose
   values don't.  Adding operations to dictionaries to insert keys, etc.,
   without having to supply a value, naively appears no harder than adding
   operations to lists, and would probably be much easier to explain when
   teaching a class.

3. (Long-term speculation) Even if P3K isn't written in C++, many modules
   for it will be.  It would therefore seem sensible to design P3K in a
   C++-friendly way --- in particular, to align Python's container  
   hierarchy with that used in the Standard Template Library.  Using lists
   as a basis for sets would give Python a very different container type
   hierarchy than the STL, which could make it difficult for automatic
   tools like SWIG to map STL-based things to Python and vice versa.
   Using dictionaries as a basis for sets would seem to be less
   problematic.  (Note that if Wadler et al's Generic Java proposal
   becomes part of that language, an STL clone will almost certainly
   become part of that language, and require JPython interfacing.)

On a semi-related note, can someone explain why programs are not allowed
to iterate directly through the elements of a dictionary:

   for (key, value) in dict:
      ...body...

Thanks,

Greg

      "No XML entities were harmed in the production of this message."