Decorator for Enforcing Argument Types

[John Machin]

Peter  Wang wrote:
> Bruno Desthuilliers wrote:
> > <my humble opinion>
> > Python is dynamic, and fighting against the language is IMHO a really
> > bad idea. The only places where theres a real need for this kind of
> > stuff are when dealing with the "outside world" (IOW : inputs and
> > outputs). And then packages like formencode can do much more than mere
> > type-checking
> > </my humble opinion>
>
> I don't think proper use of type checking is "fighting against the
> language".  The goal of any language is to enable programmers to
> express their intent in a form that executes correctly.
>
> Python is extremely expressive but there is a trade-off with
> correctness - you can easily say something that you don't mean.  Unit
> testing is sometimes sufficient, but it can never span the infinite
> space of potential errors.  Type-checking method signatures guarantees
> a certain amount of low-level correctness, and most type-checking
> mechanisms also serve as documentation aids.
>
> I think that with a sufficiently sophisticated type checking syntax,
> one can get the best of both worlds.  If the type checker understood
> interfaces (like PyProtocols) and its syntax had the flexibility to
> indicate sets of allowed arguments and aggregates of allowed
> types/interfaces, it would cover the majority of cases without limiting
> expressive power.
>
> I understand that we're all adults, but it's still nice to have the
> computer tell us when we're being childish. :)

Your comments on the following cut-down and disguised version of a
*real-world* example would be appreciated:

    @accepts(object, (int, float))
    def tally(self, anobj):
        self.total += anobj

I assure you that the comments of a caller whose code did this:
    fubar.tally(someobj)
and got this:
    AssertionError: arg 12345678901L does not match (<type 'int'>,
<type 'float'>)
are definitely *not* repeatable in front of the children.