Type checking

[George Sakkis]

Explicit type checking is not typically seen in Python code, and usually
that's not a big problem; most typing errors are likely to raise a TypeError
or AttributeError sooner than later. There are cases, though, where typing
errors are not caught (at least not early) because different classes happen
to have methods with the same name; that's really subtle with the special
methods like __eq__, __hash__, etc. that are common to all (or at least
many) classes.

It happened to me when I was passing arguments of some type B to a function
instead of the correct type A; these arguments were entered as keys in a
dictionary, and since both A and B were hashable the interpreter didn't
complain. Of course, when later I was trying to retrieve the A()s I thought
I had entered, I couldn't find them (debugging was even harder in this case
because B was essentially a wrapper for A and the __str__ of both classes
was deliberately the same, so the A()s appeared to be in the dict; that's
not the issue here though).

I wonder if people have come up with such pitfalls in practice or I was just
careless. In any case, I was tempted enough to write a simple extensible
runtime type checking module, which can be handy, at least during
development. It's extensible in the sense that a "type" can be any
constraint, not just a python type or class. Here's an example of usage:

def foo(name, age, children, phonebook):
assert TypeChecker.verify(
(age, int),
(name, TupleOf((str,str))),
(children, ListOf(Child)),
(phonebook, DictOf(str, ContainerOf(Phone))))

foo(name = ("Paul", "Smith"),
age = 23,
children = [Child(), Child()],
phonebook = {
"Mike": (Phone(), Phone()),
"office": [Phone()]
})

ContainerOf, TupleOf, ListOf and DictOf are all extensions of the abstract
TypeChecker class, providing some limited but common templated-type
checking. Of course in practice most complex structures (e.g. phonebook)
would be encapsulated in a class, so it's questionable whether such
functionality adds up anything to a list of "assert isinstance(object,type)"
statements. Any ideas or suggestions are welcome.

George

[Christopher T King]

George Sakkis wrote:

I wonder if people have come up with such pitfalls in practice or I was just
careless. In any case, I was tempted enough to write a simple extensible
runtime type checking module, which can be handy, at least during
development. It's extensible in the sense that a "type" can be any
And in other places: some functions need to behave differently depending
on the types of their arguments. When interfaces come into play,
isinstance() just doesn't cut it.
ContainerOf, TupleOf, ListOf and DictOf are all extensions of the abstract
TypeChecker class, providing some limited but common templated-type
checking. Of course in practice most complex structures (e.g. phonebook)
would be encapsulated in a class, so it's questionable whether such
functionality adds up anything to a list of "assert isinstance(object,type)"
statements. Any ideas or suggestions are welcome.

Along with TupleOf, ListOf, DictOf, etc., include interface checkers,
such as SequenceOf and MappingOf. People will love you for it.

[George Sakkis]

Christopher T King <sq******@WPI.EDU> wrote in message news:<Pi**************************************@ccc 1.wpi.edu>...

(...) some functions need to behave differently depending
on the types of their arguments (...)

Uhm.. this doesn't seem very OO to me; if a function needs to behave
differently for different argument types, it's an indication that it
should be defined as method, overriden for each type of interest (or
multiple-dispatched if more than one arguments are involved).

George

[F. GEIGER]

George, don't forget to have a look at the Traits package of scipy.

HTH
Franz

George Sakkis wrote:

Explicit type checking is not typically seen in Python code, and usually
that's not a big problem; most typing errors are likely to raise a TypeError
or AttributeError sooner than later. There are cases, though, where typing
errors are not caught (at least not early) because different classes happen
to have methods with the same name; that's really subtle with the special
methods like __eq__, __hash__, etc. that are common to all (or at least
many) classes.

It happened to me when I was passing arguments of some type B to a function
instead of the correct type A; these arguments were entered as keys in a
dictionary, and since both A and B were hashable the interpreter didn't
complain. Of course, when later I was trying to retrieve the A()s I thought
I had entered, I couldn't find them (debugging was even harder in this case
because B was essentially a wrapper for A and the __str__ of both classes
was deliberately the same, so the A()s appeared to be in the dict; that's
not the issue here though).

I wonder if people have come up with such pitfalls in practice or I was just
careless. In any case, I was tempted enough to write a simple extensible
runtime type checking module, which can be handy, at least during
development. It's extensible in the sense that a "type" can be any
constraint, not just a python type or class. Here's an example of usage:

def foo(name, age, children, phonebook):
assert TypeChecker.verify(
(age, int),
(name, TupleOf((str,str))),
(children, ListOf(Child)),
(phonebook, DictOf(str, ContainerOf(Phone))))

foo(name = ("Paul", "Smith"),
age = 23,
children = [Child(), Child()],
phonebook = {
"Mike": (Phone(), Phone()),
"office": [Phone()]
})

ContainerOf, TupleOf, ListOf and DictOf are all extensions of the abstract
TypeChecker class, providing some limited but common templated-type
checking. Of course in practice most complex structures (e.g. phonebook)
would be encapsulated in a class, so it's questionable whether such
functionality adds up anything to a list of "assert isinstance(object,type)"
statements. Any ideas or suggestions are welcome.

George