Quoth Paul Rubin <http://[EMAIL PROTECTED]>:
| Donn Cave <[EMAIL PROTECTED]> writes:
| > What this proves is that you can implement
| > an argument list at run time, but it by no means changes the
| > nature of the argument list as a sequence.
|
| Right, it's treated as a sequence rather than a record structure.
| So is that consistent with the "tuples are record structures" view,
| as opposed to the "tuples are immutable lists" view?
A struct is a sequence, and your stdargs example is a pretty good case
in point.
When I said the function implemented with stdarg (...) support needs
information about its parameters to simulate a normal function, that
applies not only to the order of parameters but also their type.
Because -- as with structs, but unlike arrays -- the parameter list
has variable alignment to accommodate different sized types. So the
C parameter list really has every property of a struct -- naturally
contains mixed types, has variable alignment, normally accessed by name --
but it does have a defined order, and stdarg is a gimmick that uses it.
Order IS the struct property that you get from a tuple, so it is of
course important that the tuple is a sequence. The point is not whether
it's a sequence or not, but what kind of order it represents.
What I'm saying with the evidently overly abstract discussion in previous
posts, is that in a struct-like application, a tuple's order is of a
different nature than a list. Because in such application, that order
is absolute and in a sense atomic. Like a struct. Like an argument list.
That's why tuple has different applications than list, that's why it lacks
some of the sequential access features that lists have.
This must be more obvious in other languages that have a tuple type.
None that I know of support so many list or array sequence operations
on tuples, and in at least some the struct/record type is implemented
by adding names to a tuple but can still be treated as one (like Python's
mtime and stat types.)
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
