Returning none

[C.Laurence Gonsalves]

On Fri, 3 Sep 1999 09:19:14 -0500, Gordon McMillan <gmcm at hypernet.com> wrote:
> C. Laurence Gonsalves wrote:
> 
> > Perhaps your programming style is different than mine. I know I've
> > frequently run into situations where I've forgotten to actually
> > return the result I calculated. Apparently others have as well. I'm
> > also sure there is a lot of code that ignores return values. There's
> > a way to add checking for this as well...
> 
> I won't pretend I've never been bitten by this, or that it's always 
> easy to track down. But when I learned Pascal (my 4th language, I 
> think), I found the distinction between functions and procedures to 
> be very tiresome. A dozen years later when I had to write PL/SQL, I 
> had the same reaction. It means that for almost every call I make, I 
> have to remember or look up whether it's a function or a procedure. 

Huh? Why would you have to look this up? Function calls and procedure
calls look identical in Pascal, don't they? (It's been a while...) 

In any case, C has a distinction between "void functions" versus
"non-void functions" in C. Do you have to go look it up every time you
call a function in C?

> I guess I have more sympathy for the functional style, though I find 
> the no side-effects restriction extreme. So Python's liberal rules 
> (side effects allowed) and consistency (everything returns a result, 
> whether desired or meaningful) are, to me, just dandy.

I don't see why it would be a problem then if an exception were thrown
whenever a function had no value to return, and you tried to grab it.
You could continue programming as you do now, but the runtime would
start warning you when you try to get the value of a function that
returned nothing. The only people this would hurt would be those who say
"return" or fall off the end when they actually want to return the value
None (as opposed to nothing). But that's sloppy, so they deserve what
they get...

> So put me firmly in the camp that favors a stronger PyLint (I just 
> recently got bit by a rarely used bare return in some released code).

This is akin to saying array-bounds checking should be done by PyLint
rather than the runtime. The problem is, a lot of these checks simply
can't be done statically.

In fact, while I was originally proposing some compile-time checks as
well, I've basically given up on those. They were mostly incomplete
(Python is too dynamic to be able to do much static checking in this
situation) and Tim found a real problem with them.

I think the runtime checks I proposed would be useful though, and I
don't think they'd break very much existing Python code.

-- 
  C. Laurence Gonsalves            "Any sufficiently advanced
  clgonsal at kami.com                 technology is indistinguishable
  http://www.cryogen.com/clgonsal/  from magic." -- Arthur C. Clarke