PEP 3107 and stronger typing (note: probably a newbie question)

Paul Rubin http
Sun Jul 8 08:27:08 CEST 2007

"Hamilton, William " <whamil1 at> writes:
> > Why on earth would anyone prefer taking a failure in the field over
> > having a static type check make that particular failure impossible?
> Because static typechecking won't make that particular failure
> "impossible,"  but instead just change it from a type error into a data
> error that may or may not be harder to identify.  If your program gets a
> piece of data that breaks it, you'll get a failure in the field.  Static
> typechecking won't prevent that.  

I'm not doing a good job explaining that regexp example.  Static
checking a la Haskell and ML avoids these problems by:

  1) noticing through case analysis that you actually handle the
     error return (except it looks like you have to use a separate
     tool for this in Haskell, sigh); and

  2) (in Haskell) using monadic types to propagate match results from
     one operation to another, automatically taking care of turning
     a match failure in a chain of operations into a failure of the
     whole chain.

In Python it's all too common to say

     g1 = re.match(pattern, string)
     a =
     g2 = re.match(template % a, other_string)
     result =

or stuff like that, without bothering to check for match failures,
just because of Python's inconvenient syntax.

This article explaining Haskell's Maybe typeclass (what you'd use
instead of returning None in a Python function) may be of interest:

More information about the Python-list mailing list