Returning none

[Tim Peters]

[clgonsal at kami.com]
C>     def calcStuff(x):
C>         if isGood(x):
C>             return x*42;
C>         else:
C>             kablowie( "x is bad!" )
C>
C>     def kablowie(s):
C>         raise "Argh: " + s
C>
C> The static checks would incorrectly think calcStuff was
C> inconsistent.
C> You can't trace into kablowie from calcStuff, because there's no
C> telling what the value really is at runtime when I call calcStuff.

[Skip Montanaro]
> If Tim gave it as an example, he's probably used it in his own code
> somewhere with good reason <wink>, but anybody else caught
> programming that way ought to be shot.

Let's generalize that:  everyone other than Tim should be shot period.

Oh, all right.  Everyone other than Tim and Skip.  Not sure about Guido.
Ya, OK, him too.  Gordon?  Eeeeew, I can't really recommend *killing* him
with a clear conscience.  That tears it!  Nobody gets shot, everybody lives.

Anyway, the kind of function-raises-an-exception trick showed above is the
cat's meow in some contexts.  For example, in the std test suite's
test_long.py you'll find:

def check(ok, *args):
    if not ok:
        raise TestFailed, join(map(str, args), " ")

and 45 invocations of the form

    check(x ^ ~x == -1, "x ^ ~x != -1 for", x)

It would be very irritating to write out & maintain the expanded forms by
hand, and using asserts instead would be Wrong since the test is useless if
it vanishes into nothingness when run under -O.  The doctest.py framework
supplies a much nicer approach to both problems, but that's not appropriate
for the std test suite either.

So bite this bullet; embrace chaos; give to the poor.

> A spurious warning from either the compiler or PyLint wouldn't be
> such a bad idea in this case.

I agree, although if I did this kind of thing a *lot* (in which case, I
should be shot <wink>), I'd put in

     return 0   # shut up stupid PyLint

lines.  Over the long haul, "treat every warning as an error" is the only
way to do software.

> ...
> I don't think it's a big enough problem to warrant changing the
> language.

The careful reader may be able to infer the same position in my own recent
ineffably subtle posts <snort>.

Let's shift the ground of the debate:  I'd bet Guido's life that this won't
go into 1.6, and I think most long-timers would agree with that regardless
of their opinion of the technical merits pro or con (new keyword?!  more
likely Tom Christiansen posts 10 energetic msgs bemoaning the lack of Python
docs in PowerPoint format <wink>).  But what about Python2?  If there were a
clean way to plug the hole in that, would you object?

Having asked that, I think I at least halfway object to the very question,
since it's a distraction from attacking much bigger insecurities.

leap-over-a-glass-shard-and-land-in-a-bear-trap-ly y'rs  - tim