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

Discussion in 'Python' started by Hamilton, William, Jul 5, 2007.

  1. > From: Paul Rubin
    >
    > greg <> writes:
    > > > E.g. your program might pass its test and run properly for years
    > > > before some weird piece of input data causes some regexp to not

    quite
    > > > work.

    > >
    > > Then you get a bug report, you fix it, and you add a test
    > > for it so that particular bug can't happen again.

    >
    > 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.


    --
    -Bill Hamilton
    Hamilton, William, Jul 5, 2007
    #1
    1. Advertising

  2. Hamilton, William

    Paul Rubin Guest

    "Hamilton, William " <> 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
    Paul Rubin, Jul 8, 2007
    #2
    1. Advertising

  3. Hamilton, William

    Chris Mellon Guest

    On 07 Jul 2007 23:27:08 -0700, Paul Rubin
    <"http://phr.cx"@nospam.invalid> wrote:
    > "Hamilton, William " <> 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.
    >


    I don't think it's the syntax that keeps people from checking for
    errors. It's more a difference of error handling philosophy - in
    Python, if you can't do something sensible with an error you just
    pretend it can't happen and rely on your caller to do something
    sensible. In a lot of cases, this means that nobody does anything and
    errors propagate all the way up and thats fine.

    What you're describing with the type inference solution feels more
    like Javas checked exceptions to me, where the compiler ends up
    signaling an error if you don't pretend like you considered the error
    condition. In Java, at least, this tends to create actively harmful
    code where you stick in empty or otherwise useless exception handlers
    to shut up the compiler, and when "can't happen" errors actually do
    occur they are lost or worse. Maybe this doesn't happen in Haskel, but
    I'd be interested in how it doesn't.
    Chris Mellon, Jul 9, 2007
    #3
  4. Hamilton, William

    Donn Cave Guest

    In article <>,
    "Chris Mellon" <> wrote:

    > I don't think it's the syntax that keeps people from checking for
    > errors. It's more a difference of error handling philosophy - in
    > Python, if you can't do something sensible with an error you just
    > pretend it can't happen and rely on your caller to do something
    > sensible. In a lot of cases, this means that nobody does anything and
    > errors propagate all the way up and thats fine.
    >
    > What you're describing with the type inference solution feels more
    > like Javas checked exceptions to me, where the compiler ends up
    > signaling an error if you don't pretend like you considered the error
    > condition. In Java, at least, this tends to create actively harmful
    > code where you stick in empty or otherwise useless exception handlers
    > to shut up the compiler, and when "can't happen" errors actually do
    > occur they are lost or worse. Maybe this doesn't happen in Haskel, but
    > I'd be interested in how it doesn't.


    As Paul mentioned parenthetically, Haskell's type system doesn't
    support all this by itself. You can write a function that is defined
    for only some cases of a value, so indeed you can fail to check for
    an error status, or match the first element of an empty list, and
    in general it is quite possible to get a run time error in this way.
    There is naturally some dissatisfaction with this state of affairs.
    Another point about this is that a

    The second point, about syntax and failure handling is another matter.
    In the example -
    >
    > g1 = re.match(pattern, string)
    > a = g2.group(0)
    > g2 = re.match(template % a, other_string)
    > result = g2.group(1)
    >


    .... if all these re functions have a monad type that supports it,
    this would be a sequence of monad bindings with failure options.
    The algebra of these things is such that a failure short circuits
    the larger expression just like a false result short circuits
    evaluation of an "and" sequence. I wouldn't say this prevents
    data errors in Haskell, though, it only simplifies them in a sequential
    computation where such a monad type is convenient.

    I missed the type error -> data error point that this evidently
    was all supposed to be some response to, and I don't know what
    that was supposed to mean, but Haskell's type system addresses
    just what we all would expect, the structural consistency of the
    program in terms of data types. It doesn't generally prevent data
    errors or correct your misunderstanding of an algorithm or in
    general avoid every kind of error. What it does, though, it does
    rather well.

    Donn Cave,
    Donn Cave, Jul 11, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tony Lownds
    Replies:
    4
    Views:
    450
    Tony Lownds
    Jan 1, 2007
  2. =?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=

    Re: PEP 3107 Function Annotations for review and comment

    =?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=, Dec 30, 2006, in forum: Python
    Replies:
    9
    Views:
    350
    Tony Lownds
    Jan 1, 2007
  3. Stephen R Laniel
    Replies:
    160
    Views:
    2,150
    Hendrik van Rooyen
    Jul 22, 2007
  4. Christoph Zwerschke

    Missing exceptions in PEP 3107

    Christoph Zwerschke, Aug 9, 2008, in forum: Python
    Replies:
    15
    Views:
    426
    Carl Banks
    Aug 18, 2008
  5. JimLad
    Replies:
    0
    Views:
    486
    JimLad
    Jan 26, 2010
Loading...

Share This Page