[Python-ideas] Proposal for extending the collections module - bags / multisets, ordered sets / unique lists

[Mike Meyer]

On Sun, 19 Jul 2009 04:00:48 -0300
Leonardo Santagada <santagada at gmail.com> wrote:
> On Jul 19, 2009, at 1:31 AM, Mike Meyer wrote:
> > On Sun, 19 Jul 2009 11:28:37 +1000
> > Steven D'Aprano <steve at pearwood.info> wrote:
> >>>> for card in cards:
> >>>>    if hand.count(card) == 2:
> >>>>        print('You have a pair.')
> >> Why would a class with unique=True have a count() method?
> >
> > So that you can write code that doesn't care which of the various
> > flavors of collection it gets passed, but will work on them
> > anyway.
> >
> > It supports a property of classes in OO programming called
> > "polymorphism". It's a good thing. That python's collections don't
> > have it has always been a minor wart, and it gets bigger as we get
> > more types of collections.
> For example ints don't support slicing and that is not an omission of  
> polymorphism, there is no sense in having that on them.

Given that there aren't any types related to int for which slicing
makes sense, this is true.

> A dict or set having a count method would make no sense either. This
> has nothing to do with polymorphism.

Actually, count on a dict makes *lots* of sense. I can think of a lot
of uses for counting the number of occurrences of values in a
dictionary, mostly revolving around using dictionaries to implement
sparse arrays of various kinds.

As for sets, the "count" method is obviously useful on multisets. And
it takes on reasonable values for the subset of multisets with unique
values. Yes, it's either 1 or 0, and yes, it's isomorphic to testing
membership, but it makes sense. An algorithm that uses count on
multisets should work just fine on sets - that's what polymorphism
buys for you. Saying that "count" doesn't make sense on sets is a lot
like saying "length" and "width" don't make sense on squares, since
those are equal - which would mean code written to handle rectangles
wouldn't work on squares, unless they were crammed into rectangle
objects.

Part of the problem is that Python's collections types are a
collection (no pun intended) of things that have shown themselves to
be useful in practice.  This has resulted in types that have nearly
identical sets of operations on them, but the operations have
different names, so the types - which would be polymorphic if they'd
been designed to work together - aren't polymorphic. I get bit by this
fairly often. Most recently spending last friday afternoon auditing
code to make sure I'd turned all the list methods into the appropriate
set methods in a graph class's node walking method.

> add on lists or append on sets could be discussed (maybe append on  
> sets makes more sense as they already have pop), but adding count in  
> dict or set would not be pragmatic.

Nah, it'd just be useful.

     <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org