Typing system vs. Java

Skip Montanaro skip at pobox.com
Thu Aug 2 18:41:44 CEST 2001


    David> Or perhaps better, a compile-time error that 'parse' has an
    David> implicit 'return None' at the end. Of course, adding that would
    David> mean that this:

    David> def three_plus_1_problem(n):
    David>     while 1:
    David>        if n == 1: 
    David>           return 1
    David>        if x % 2 == 0:
    David>           n = n / 2
    David>        else:
    David>           n = 3*n + 1

    David> would also be an error; you'd have to throw an extraneous return
    David> at the end. Personally, I could live with that for the extra
    David> sanity checking.

And you thought the division change would break a lot of code!  There's
nothing wrong with execution falling off the end of the function.  Python
was designed that way.  It's when there are explicit returns and the
implicit return is reachable that you need to warn about a potential
problem.

A fairly small amount of analysis can detect that the implicit return is
never reached (I did such a thing for a peephole optimizer).  In that case,
all I did was toss out any unreachable code block.  It would be sufficient
to detect that the last return is reachable and emit a warning if there was
another return executed in the body of the function.  This would be okay:

    def foo(a):
        if a == 0:
            return 1
        elif a == 1:
            return 0
        else:
            return a*5

because that final implicit return is unreachable.  This would emit a
warning though:

    def foo(a):
        if a == 0:
            return 1
        elif a == 1:
            return 0

-- 
Skip Montanaro (skip at pobox.com)
http://www.mojam.com/
http://www.musi-cal.com/




More information about the Python-list mailing list