On Sun, 19 Jul 2009 04:00:48 -0300 Leonardo Santagada <santagada@gmail.com> wrote:
On Sun, 19 Jul 2009 11:28:37 +1000 Steven D'Aprano <steve@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
On Jul 19, 2009, at 1:31 AM, Mike Meyer wrote: 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@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