[Python-Dev] Sets are mappings?

[Michael Chermside]

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