Purpose of Python Type Checking?

[jerf at compy.attbi.com]

On Mon, 27 Jan 2003 07:25:23 +0000, Alex Martelli wrote:

> jerf at compy.attbi.com wrote:
>> I use it in my code generally as a combination of those two; I believe in
>> "try it and see, but if it fails it must fail atomically", i.e., a failure
>> does not change anything in the data structure. If I can not guarentee
> 
> I find a (very occasional) need for such "low-level atomicity" (more
> often the atomicity must be ensured as part of a larger transaction
> in an ACID context and thus it's not very useful to bend over backwards
> to also guarantee it to such fine granularity), and have documented
> the approach as a recipe in the Python Cookbook, online at:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52291

I still don't like that because just because class A has an "insert"
method and class B has an "insert" method does not mean that it means even
remotely the same thing, even if they have the same signiture. The fact
that the "Tag" class requires an explicit wrapping is a feature, not a
bug: First, I wouldn't expect that there will exist a class anywhere that
wouldn't *already* require a wrapper to work in my system, so adding the
Tag is about 10 chars more. Second, the Tag functions as a semantic kind of
declaration that "Yes, I mean *your* insert, not a list insert, not an
array insert, not an insert-tab-a-into-slot-b insert". If I'm going
through the effort of checking, I want to be *right*, such that it's the
other programmers 'fault' if they don't maintain the contract.

It's like a namespace for methods, sort of. Or a protocol declaration,
albiet a weak one. Simple name correspondence isn't enough to satisfy me
on those rare occasions I care.

That said I just looked through the code I've been thinking of and I
recently refactored it such that there are only two type checks now: One
in an equivalency-checking function to make sure two objects have the same
__class__ (a valid question in an equivalency determination, and only used
for automated testing anyhow), and the other to implement an (optional!)
feature where a node can declare that it will only accept certain types of
children, which makes sense to me. There used to be more but it looks like
they got eliminated in the refactoring. The first case is a wash anyhow,
because it's only used in testing, but in the second, *all* the subclasses
have method name equivalence; actual type checking is necessary, and there
are definately use cases where such a thing is desirable in my app. (And
by use cases, I mean that end-users will appreciate it, not just
developers.)