[Python-Dev] Sets are mappings? (original) (raw)

Michael Chermside mcherm at mcherm.com
Wed Dec 21 14:45:38 CET 2005

Josiah Carlson writes:

New superclasses for all built-in types (except for string and unicode, which already subclass from basestring).

int, float, complex (long) : subclass from basenumber tuple, list, set : subclass from basesequence dict : subclass from basemapping The idea is that each of the above classes define a group in which items are comparable.

Nick Coghlan writes:

Close enough to on-topic to stay here, I think. However, I tend to think of the taxonomy as a little less flat:

basecontainer (anything with len) - set - basemapping (anything with getitem) - dict - basesequence (anything which understands x[0:0]) - list - tuple - string - unicode - basearray (anything which understands x[0:0,]) - Numeric.array/scipy.array

Hold on a sec folks!

I really don't understand why we are trying to build a taxonomy of container classes. There are some languages which have rather elaborate taxonomys of container classes. The STL comes to mind, Smalltalk (I think), even Java's collection classes are somewhat elaborate. But this is NOT how things have been done in the Python world. We believe that flat is better than nested. We believe in one simple-and-obvious way to do things. For goodness sakes, we don't even have a basic linked-list type because we figure it's simpler to make people just use the single well-tuned array-list implementation.

Furthermore, I AGREE with this choice. I realize that in THEORY, a list is simply a bag with the extra feature of ordering, and that a list you can iterate backward is just an iterate-only-forwards list with an extra feature. But I have never found it USEFUL in practice. In languages that support it, I hardly ever find myself saying "well, I'm planning to pass a list, but this method really only needs a bag... it doesn't matter whether it is ordered", then later finding that this made it easy to re-use the method when I had some other bag implementation. Frankly, I find this sort of re-use MORE likely in Python simply because of support for duck typing.

So I have a counter-proposal. Let's NOT create a hierarchy of abstract base types for the elementary types of Python. (Even basestring feels like a minor wart to me, although for now it seems like we need it.) If the core problem is "how do you create a canonical ordering for objects that survives serialization and deserialization into a different VM?", then somehow abstract base types doesn't seem like the most obvious solution. And if that's not the problem we're trying to solve here, then what IS? Because I don't know of very many ACTUAL (as opposed to theoretical) use cases for abstract base classes of fundamental types.

-- Michael Chermside

More information about the Python-Dev mailing list