Returning none

[Michael P. Reilly]

C.Laurence Gonsalves <clgonsal at keeshah.penguinpowered.com> wrote:
: On Sat, 28 Aug 1999 04:05:31 -0400, Tim Peters <tim_one at email.msn.com> wrote:
[insert Ivan's "bobbitt/seminal" mayan glyph here]

:> > I don't think it's too hard to explicitly return None when that's
:> > what you want to do, and I would think/hope that most existing
:> > Python code does this already.
:> 
:> Python doesn't return None for the convenience of people too lazy to
:> explicitly return None themselves; it's instead a cheap way to make it
:> probable that someone using a procedure as a function will get an
:> error (None supports no operations except true/false interpretation)
:> without blowing up the interpreter (do this in C and you'll access
:> random stack trash).

: That sort of argument also says that when I go outside the bounds of a
: list in Python, I should get back None, since in C I would access random
: stack/heap trash. Instead, Python raises an exception. I think it should
: do the same if you don't return anything, and then try and access that
: nothing.

: While None does have few operations, the current behaviour does not
: guarantee a runtime error. I've very often built-up sequences filled
: with None's, or assigned None to the attributes of some object. The
: program ends up failing much later. I think it's best for Python to fail
: as close to the source of the problem as possible. Ironically, this
: "failing much later" is the same kind of behaviour you get with C
: programs that access random stack trash...

: That's why I also suggested some other possible rules that would enable
: some amount of compile-time checking, so that function writers who do
: questionable things would be alerted.

[another of Ivan's "snipping" glyphs]

: In another post I suggested another idea that requires little or no
: modifications to the grammar, but would just add some new runtime and
: compile time checks. Functions using return (or falling off the end)
: would return nothing at all (rather than None), and function definitions
: would require that the function either always return a value, or never
: returns a value. This can be very easily checked at compile time. At
: runtime, attempting to retrieve the return value of a function that
: returns nothing would raise an exception. This check could even be done
: before actually executing the function at all.

I'm guessing that most everyone has forgotten what "None" _is_.  From
Python Reference Manual: 3.2 "The standard type hierarchy":

   None
          This type has a single value. There is a single object with
          this value. This object is accessed through the built-in name
          None. It is used to signify the absence of a value in many
          situations, e.g., it is returned from functions that don't
          explicitly return anything. Its truth value is false.

The key here folks is "the absense of a value".  None means "nothing at
all" that the "procedure" proponents are all for.  It's doing exactly
what you want, you may just be thinking of it incorrectly (we all are
probably thinking of None incorrectly at times).

If you want to not include "return" in your functions, or to require
that your code must "return None" that's fine.  I think that the
argument is that the language is not going to improve by requiring
procedures.

  -Arcege