Nick Maclaren wrote:
>
> Which is tantamount to saying that Python doesn't support mutable
> heterogeneous sequences, even though they are not locked out. That
> is more than just odd - it is almost unbelievable. They are a very
> basic data structure, after all!
What a fuss about something so intangible! :-) If I were you, I'd not
worry about taking what people say with regard to the philosophy as a
starting point. Instead, it may be more illustrative to consider things
from the ground up...
* You can put any combination of things into both tuples and lists.
* Tuples are immutable, lists are mutable.
* You can test both tuples and lists for element membership
(x in seq).
* You can iterate over both tuples and lists.
The contentious issue is why you can't ask where something is in a
tuple (the position of an element) whereas you can in a list or even in
a string (albeit only with substrings in that particular case). This is
where you have to consider how you'd use an immutable sequence like a
tuple rather than a mutable sequence like a list.
With a tuple, since you can't append to it, you already need to have
decided its size and its contents (mutable elements notwithstanding)
when you create it. Although it's possible to have thousands of
elements in a tuple, you would in most situations need to build such
long tuples up either by concatenating existing ones - this is not
likely to be particularly efficient due to the need to construct a new
tuple for each concatenation of existing ones - or by converting a list
into a tuple (questioning the need for a tuple, anyway). So it's
unlikely that you'd lightly consider using tuples as an ad-hoc sequence
for recording long collections of objects, or that the structure of any
tuple you've created is consequently going to be unknown to your
program. Even if you were dealing with totally unknown tuples from
other sources, the need to query the location of specific elements
would probably be much less than just iterating over the tuple or
asking whether something is present in it.
Of course, one can still argue that querying for the presence of an
element is no real substitute for knowing its position. In a program
where you define the structure of a tuple in such a way that it makes
little sense for a particular element to appear in more than one place
- which is where the heterogeneous assertion comes in - knowing the
presence of an element is as good as knowing its position (since the
program has knowledge of the position implicitly). In a program where
you don't define the structure in such a way, the problem situation
seems to be as narrow as needing short tuples (as opposed to lists,
possibly for use as dictionary keys, for example) whose elements'
locations are efficiently discoverable, and where such location
information is significantly useful for other purposes. Since tuples
are immutable, you can't replace those elements using such location
information, leaving fewer and fewer compelling reasons for needing
that information in the first place, I would have thought.
Perhaps the notion of heterogeneous is best defined in the most general
case as a selection of objects unlikely to be considered equal or
equivalent, in such a way that the standard test for presence (x in
seq) employs such a measure of equality and can suggest (with
contextual information) the location of an object by just knowing
whether it is present.
Paul
--
http://mail.python.org/mailman/listinfo/python-list
