Wed 7 Dec 2005
The typecheck project grew out of a desire to gain more safety in my python programs. Whereas the majority of the python community seems to be in love with (or at least, “ok with”) the idea of duck-typing, duck-typing has always struck me as a post-fact rationalisation of the decision to make python a weakly-typed language. In less fancy language: I hate duck-typing so much, I’m willing to spend a few months developing a way to get away from it.
So, what is the typecheck package? At its most primative, it provides a way to make sure the arguments to your functions, methods and generators (and their return values) are of the expected types. Going further, it offers a wealth of extensibility, allowing — and expecting — programmers to push it much further than simple “is argument ‘a’ an integer?” typechecking. Beyond this rudimentary mode of operation, the typecheck package ships with the following tools:
-
Utility classes allowing the programmer to build up more complex “types” from boolean expressions. Though the And(), Not() and Or() classes can of course be used with all built-in and user-defined types, they can also be nested within one another to produce all other boolean operators.
-
Other utility classes exist to enforce duck-typed constraints. For example, IsCallable() asserts that the object can be invoked like a function, and IsIterable() ensures that you’ll be able to utilise the object in for loops. A HasAttr() class is provided, allowing assertions that the object has certain, specified attributes.
-
The typecheck package borrows the concept of “type variables” from languages like Haskell. Type variables allow you to say, “I don’t care what type parameter ‘a’ is, but parameters ‘c’ and ‘d’ need to be of that same type, as does the function’s return value.”
Beyond these standard tools, care has been taken to allow, for example, user-defined container classes to hook into the typechecker, providing type safety for the most exotic of classes. For simple iterator container classes, mixins exist to provide drop-in typechecking capabilities.
The project’s website is: http://oakwinter.com/code/typecheck/. There, you’ll find links to more complete documentation, the project’s Subversion archive, and source and Python Egg distributions.
My involvement - the original typecheck project was developed by Iain Lowe. In Fall 2005, I started working on my own typechecker to address certain limitations of Iain’s code, though also intending to keep full, interface-level backwards compatibility with what he had done. In November 2005, I felt my codebase was complete enough for a 0.1 release and so contacted Iain about merging our projects. He agreed, and my code became the core of the combined typechecker. I’m currently leading the coding and documentation work on the project.
January 4th, 2006 at 11:10
[…] This was something that I hadn’t anticipated when designing the API, the need to say “the following commands need to be executed, but I don’t care in what order”. The next few days are a blur, resulting in a near-total reworking of svnmock’s internals. The end result looks very much like typecheck’s internals: a set of plug-in style classes that do all the work, controlled by a single dispatcher. […]