f---ing typechecking

[Donn Cave]

In article <7xfy97uhv0.fsf at ruckus.brouhaha.com>,
 Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:

> Donn Cave <donn at u.washington.edu> writes:
> > If t is a valid argument tuple for function f, then can t[1:]
> > also be a valid argument tuple for function f?
> > 
> > For ordinary functions without special argument handling, no.
> > We know that without having to know anything about t, and not
> > much about f.  This is characteristic of tuple applications.
> 
> I'm not sure what you're saying.  The current situation is if I say
> 
>    def f(*args):
>       print args
>    
>    f (1,2,3,4,5,6,7)
> 
> f receives a 7-element tuple, but if I say
> 
>   f (8, 9, 10)
> 
> f receives a 3-element tuple.

OK, and of course

 - f has some implementation which assigns meaning to each
   parameter, according to its position.

 - it does this by assigning names to those positions (this isn't
   essential to my point, but reinforces the struct analogy)

For any basic, no-tricks implementation of f, the second application
is going to have problems:

 - fourth and following positions have no actual parameters

 - if you meant to portray (8, 9, 10) as t[4:], where t is
   (_, _, _, _, 8, 9, 10), following my proposition above,
   then it should be clear that inasmuch as t[4] for example
   has some meaning in terms of f, one cannot preserve this
   meaning in a smaller slice of t.  Please think about it,
   because I do not intend to try to explain this again.

So the parameters of f form a sort of type -- an ordered sequence
of values, where each item has a different meaning according to
its absolute position in the sequence, and where a name is assigned
(by at least f and optionally by its caller) to each position.
This type can be represented by many possible values, but we can
observe that just as a matter of principle, for any value of this
type, a smaller slice is not also of this type.

Of course the word "type" above is about something that is not
formally implemented in Python, so you can obtusely quibble about
whether it's a type or not, but the constraints are real.

> I'm asking whether f should receive a list instead.  I think that is
> more in keeping with the notion of a tuple being like a structure
> datatype.  How can there be a structure datatype with an unpredictable
> number of members?

Unpredictable?  How do you manage to write functions in this case?
Are all your formal parameter lists like (*a), with logic to deal
with the variable lengths?  But even that wouldn't by itself make
your point.  Any experienced C programmer is likely to have "subtyped"
a struct, adding one or more values to the end of the parent struct,
so the value can be passed to functions that expect the parent type.
Variable length isn't strictly foreign to struct types.

   Donn Cave, donn at u.washington.edu