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.
--
http://mail.python.org/mailman/listinfo/python-list
