[Doc-SIG] RE: [Types-sig] Re: documenting Python constraints on types
Sat, 2 Jun 2001 18:30:17 -0400
> 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
> - "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, , 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>.