Steven Bethard <[EMAIL PROTECTED]> writes:
> Not to advocate one way or the other, but how often do you use
> heterogeneous containers?
Pretty much everything I do has heterogenous containers of some sort
or another. SQL queries made to DP API compliant modules return
homogenous lists of heterogenous containers. The cgi module turns the
request string into a dictionary-like container of objects with values
of different types. Higher-level web interfaces go even further in
this direction.
The last thing I did that was both more than a script and didn't use
either a database or a web front end was (IIRC) a media player for
multiple media types. It revolved around lists of things to play, and
the "things" in question could be any "playable" object - video or
audio files, track on a CD, or a DVD, or even a playlist.
Come to think of it, recursive data structures of this type - a
container that contains a heterogenous list of things, possibly
including instances of the container type itself - are pretty
common. Pretty much every GUI package has something like it. All
processors of SGML-based markup languages I've ever dealt with
included something like it. MIME-encoded email does this. Page layout
programs do this. Block-structured programming languages do this. And
probably lots of others.
These are things that in a language that used classes for carrying
(and enforcing) type, all of these cases would be heterogenous lists
of objects that were subtypes of some type, so maybe they would
"really" be heterogenous. But then you're stuck with the interesting
question: What's the type relationship between two objects a and b
that allows them to be compared.
This question is still interesting with duck typing. If anything, it's
even more interesting.
We have *at least two* different proposals for a different typing
system in hand. For one, the answer is obvious. The OP proposed that
equality only be allowed when the types explicitly allow it, instead
of defaulting to typing by identity. In that one the answer is that
all the types on the list have to boilerplate so they play
together. Phrasing it that way makes it seem contrary to the spirit of
Python, as not needing boilerplat is an oft-touted strength of Python.
The other proposal - if I have it right - would not change the
behavior of equality comparisons between objects of the same class,
but would make comparisons between objects of different classes raise
an exception instead of returning false by default. Since I didn't
raise this proposal, I'll leave it up to someone else to explain under
what conditions two objects that are both instances of some class are
"the same type" or not.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
