Returning none

[C.Laurence Gonsalves]

On Sat, 28 Aug 1999 04:05:31 -0400, Tim Peters <tim_one at email.msn.com> wrote:
> [C.Laurence Gonsalves]
> > def seqToString( seq ):
> >     ...
> >     result = result + ']'
> >
> > ...
> > Personally, I think falling out of functions and expecting None to be
> > implicitly returned is a very Perl-ish thing to do...
> 
> Oddly enough not.  In the absence of an explicit "return", Perl returns the
> value of the last expression evaluated before falling off the end, so in your
> function above it returns what you intended.

Yes, in this case. I was referring to the way that Perl tries to guess
what you meant rather than treat dubious code as incorrect.

> > Why don't we add $_ to Python as well?
> 
> Because that would be Perlish <wink>.
> ...  
> The reason it doesn't fit in Python is that Python isn't specialized
> to string crunching -- or to any other particular domain.

I was being sarcastic. I was pointing out that if Python is going to
start making wild guesses about one thing, then it might as well do it
everywhere else as well. Making assumptions about what value I want to
manipulate is no less valid than making assumptions about what result I
want to return...

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

> > It is possible, but more complicated, to make this a compile time
> > error.  This would essentially require a function/procedure
> > distinction with restrictions about how you used return in each one.
> > ...
> 
> Do you imagine Guido didn't consider this when he designed the language?

So Python is *absolutely perfect* and shouldn't be changed at all? I
guess us mere mortals shouldn't even bother making any suggestions then.
Python 2 will just be Python 1.5.2 with a new name...

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.

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