PEP 3107 and stronger typing (note: probably a newbie question)
Paul Rubin
http
Sun Jul 8 02:27:08 EDT 2007
"Hamilton, William " <whamil1 at entergy.com> 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.group(0)
g2 = re.match(template % a, other_string)
result = g2.group(1)
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:
http://blogs.nubgames.com/code/?cat=2
More information about the Python-list
mailing list