Python Typechecking: The Typecheck module
About a year ago I started creating a Python library to support better typechecking in Python. Python is a fun language, but errors often hide far longer than they would in other languages, making debugging more necessary and painful than it needs to be. A trivial typo in a field setting cannot be caught by Python, for example, and type errors are never caught until an attempt is made to USE the value… which may be far, far later in the program. I really miss the ability of other languages to automatically check types, so that mistakes can be identified more directly. But I never got around to finishing my typechecking module for Python - there were just too many other things to do. Which is just as well, because someone else has done a better job.
Typecheck is a type-checking module for Python by Collin Winter and Iain Lowe; it “provides run-time typechecking facilities for Python functions, methods and generators.” Their typecheck module provides many more useful capabilities than my early typecheck module. In particular, they handle variable-length parameter lists and other goodies. These capabilities, like the assert statement, make it much easier to detect problems early… and the earlier you can detect problems, the easier it is to figure out why the problem happened.
The biggest trouble with the current verison of typecheck is that it isn’t easy to specify the right types. Since Python hasn’t had typechecking before, it doesn’t have built-in names for the types that you actually want to check against. For example, conceptually int (integer), long (arbitrarily long integer), and float are all subclasses of another type named “Number”… but there isn’t actually a type named Number to compare against (or inherit from, or implement as an interface). The same is true for “Sequence”… the Python documentation is full of discussions about Sequence, but these are merely conceptual, not something actually in the language itself. Even in cases where there is a type, such as “basestring” meaning “any string-like type”, is a type not known about by many Python developers.
Typechecking only works when people actually specify the right types, of course. If you are too restrictive (“I want only ‘int’” when any number will do), then typechecking is a problem not a help. Hopefully the typecheck implementors will find a way to define the types that people need. In my mind, what’s needed is a way to define an Interface (a list of required methods) that has an efficient implementation (e.g., it’s a singleton that caches the types that match). Then they can define critical types using the Interface type.
I look forward to using the typecheck module, once they add enough type definitions to use it well!
path: /oss | Current Weblog | permanent link to this entry