[Types-sig] Re: documenting Python constraints on types

Tim Peters tim.one@home.com
Sat, 2 Jun 2001 18:30:17 -0400

[Frederic Giacometti]
> OK. Taking the C check function as reference may not be the right thing
> (Then you might ask; Are the PySequence_Check and PyMapping_Check
> functions of any use other than checking that the the desiring protocol
> field has a non-null value in the C type defintion?

No, they aren't.

> ... but that's another debate).

?  They do what they do.  Whether that's useful depends on the purpose you
have in mind.  I'm sure Guido would prefer to drop the operator.isXXXType()
functions, since they don't *usually* do what people "think" they do.  But
what people think they *ought* to do varies by person, so it's unclear how
to improve the situation.

> I guess some further definition and formalizing work is required
> for the basic Python types / protocol.

Have you looked at Paul Prescod's recent work here?  Unfortunately, the
Types-SIG home page doesn't seem to have a reference to it.  Paul?

> Here is a step forward:
> In the same spirit as in the read-only / writable Mapping, you may
> define:
> - "Tuple" (as a non-mutable read-only sequence

Is that enough?  Sometimes the distinction of interest is that it's-- unlike
all tuples --immutable "all the way down".  This is akin to the distinction
the hash() builtin makes:  not all tuples are hashable.  This is a "shallow
vs deep" thing, e.g. (1, 2, 3) vs (1, [2], 3).  We *call* both of those
"immutable" today, but the value of the latter (as seen by "==") may
actually change over time.

> - "Vector" (items can be changed, but the sequence size is
> frozen, just like in a vector object)

What's "a vector object" <wink -- but Python doesn't have such a thing>?

> - List (anything can be done on it; modifying items, adding/removing
>   items; just like a plain list).

Including, e.g., list.sort()?  You have to be very specific -- I'm afraid
"just like" is never adequate, as different people read different things
into any gap in precision.

> Here again, with these three hierarchical protocol/interfaces
> (each one add feature the previous did not have), you cover 98% of
> the sequence situations.

I would have guessed 97.9% <wink>.