Static typing

Bjorn Pettersen BPettersen at NAREX.com
Sat Jul 26 02:34:20 CEST 2003


> From: Aahz [mailto:aahz at pythoncraft.com] 
> 
> In article <mailman.1059169958.20638.python-list at python.org>,
> Shane Hathaway  <shane at zope.com> wrote:
> >
> >Well, here's a pattern I've been trying out for this 
> purpose: use assert 
> >statements at the top of the function.
> >
> >def foo(bar, baz):
> >     assert isinstance(bar, int)
> >     assert isinstance(baz, str)
> >
> >I'm quite happy with the pattern, although there are a couple of 
> >negative points that I can think of:
> >
> >- It's a bit verbose, although that verbosity enables you to perform 
> >bounds checking and operate with other type systems like 
> Zope's interfaces.
> >
> >- You can't specify the type of the return values this way.
> 
> You skipped the crucial negative: it breaks Python's name-based
> polymorphism.  If someone creates a class that works just 
> like a string but doesn't derive from the str class, your 
> program breaks for no good reason.

And just for completeness... If you absolutely want a static type
system, that preserves Python's name-based polymorphism, google for
"bounded parametric polymorphism" or "constraint based polymorphism".
Algol/C(++)/Pascal/Java type-declarations are not nearly expressive
enough.

-- bjorn
(e.g.
http://www.cis.ohio-state.edu/~gb/cis888.07g/Papers/p388-litvinov.pdf
gives an introduction to the commonly raised issues/examples in the
context of Cecil).





More information about the Python-list mailing list