f---ing typechecking

[Donn Cave]

Quoth Paul Rubin <http://[email protected]>:
| > 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, (e-mail address removed)

 

[Nick Craig-Wood]

L=[1]
L.extend((1,))
L
[1, 1]

Are list.extend() and list concatenation supposed to behave
differently? I always thought concatenation was just shorthand
for calling extend().

They are different. list.extend() mutates the list, returning
None, while the + operator returns a new, concatenated list.

+= on the other hand works very similarly to list.extend().

It does make an inconsistency though...

L=[1]
L+=(1,)
L

[1, 1]

Wheras

L=[1]
L=L+(1,)

Traceback (most recent call last):

Ie

x += a

does not equal

x = x + a

which it really should for all types of x and a

(That is the kind of statement about which I'm sure someone will post
a perfectly reasonable counterexample ;-)

 

[Hendrik van Rooyen]

Ie

x += a

does not equal

x = x + a

which it really should for all types of x and a

One would hope so , yes.

However, I think that the first form is supposed to update in place,
while the second is free to bind a new thing to x

(That is the kind of statement about which I'm sure someone will post
a perfectly reasonable counterexample ;-)

I don't think its reasonable - its just an accident of implementation..

- Hendrik

 

[Neil Cerutti]

One would hope so , yes.

However, I think that the first form is supposed to update in place,
while the second is free to bind a new thing to x


I don't think its reasonable - its just an accident of implementation..

Yup. It's analogous to the way you can do hill-starts with a
manual transmission, but not with an automatic transmission.

 

[greg]

I don't think its reasonable - its just an accident of implementation.

There's nothing accidental about the implementation of
the in-place operators. It was designed the way it is
so that it would work in a reasonable way with both
mutable and immutable objects.