[Python-ideas] [Wild Idea] Static Ducks

Steven D'Aprano steve at pearwood.info
Tue Sep 22 02:19:51 CEST 2009

On Sun, 20 Sep 2009 10:33:55 am Dj Gilcrease wrote:
> On Sat, Sep 19, 2009 at 6:00 PM, Steven D'Aprano <steve at pearwood.info> 
> > You ignored most of my questions. I'll *guess* what your intention
> > is.
> >
> > You want the compiler to perform declarative type checking at
> > compile time, with no type inference. You're proposing a syntax to
> > declare types, with no implementation at all for how the compiler
> > should actually do that checking.
> >
> > (I'm guessing compile time because you call it *static* ducks, even
> > though you state it should raise TypeError. But you never actually
> > say whether that will be raised when the compiler compiles the
> > code, or when it runs it.)
> Actually I would say it does it at run time because of the
> requirement that it work along side code that does not use this, both
> being imported to and importing non static ducked code. In the case
> it imports code that is not using static ducks it would have to check
> anything you pass in to a method that is typed or assigned to an
> attribute that is.

I think you're unsure or confused about the different kinds of type 
systems. I don't think it makes sense to talk about static type checks 
happening at runtime -- static typing implies that the type of every 
variable is known at compile time. That's impossible in Python, 
although of course other languages (like Boo) can have static types 
with a Python-like syntax.

You should read:

It sounds like what you want is a framework for hiding the complexity of 
runtime type checkers from the developer. I don't think there's any 
need for new syntax beyond decorators and the type annotations added to 
Python 3. Type annotations give you a way of declaring types of 
arguments and return results. Although such declarations are currently 
ignored by Python, you can write code to enforce them, and decorators 
give you a neat syntax for applying that code to your functions without 
having to explicitly include the type checks inside the function body. 
You can also do the same with metaclasses.

You might also be interested in the concept of pre- and post-conditions, 
taken from Eiffel (and probably other languages as well). Guido van 
Rossum has given some example metaclasses to perform such Eiffel 
condition checks:

(See the "Real-life Examples" section.)

If you haven't already read these, you should:


Steven D'Aprano

More information about the Python-ideas mailing list