Newbies: Re: Returning none

[C.Laurence Gonsalves]

On Fri,  3 Sep 1999 07:33:09 -0500 (CDT), Skip Montanaro
<skip at mojam.com> wrote:
> 
>     Paul> #1. a=list.sort("abc"): "None object has no attribute foo" 
> 
> For those people who like to think that sort returns a new list, the
> sort method could be modified to return the list, but this would make
> people think that a and list pointed to different objects.  Then
> they'd complain that when modifying the object referred to by list,
> the object referred to by a also changed.

I think most people that have used Python for any length of time know it
would be a Bad Thing if sort were to return the list it sorted, as that
would create even more confusion. Having it return nothing instead of
None would be better than the current behaviour though.

In the above code, the "AttributeError: 'None' object has no attribute
'foo'" does not come at that line of code. It comes much later on when
you try to say 'a.foo'. If the sort method instead returned *nothing*,
then the above assignment would cause an exception to be raised on that
line, instead of much later, or possibly not at all.

    ofile.write( str( list.sort() ) )

> It's worth noting is that those people who are clamoring for a
> distinction between functions and procedures will have to figure out
> how to implement procedures in the C runtime, not just at the Python
> level.

Yes, but design comes before implementation.

>     Paul> #2. alert( print_traceback() ): "None"
> 
> This seems like a semantic problem on the programmer's part more than
> anything.  You're clearly asking the function to do something by
> side-effect.  Why would you also expect it to return a useful value?
> If I wanted the traceback in a return value I'd expect the function to
> be named "get_traceback" or "extract_tb" or something similar.

True. But the function does return something. That's the problem. It
returns None. It would be better if it returned nothing at all, rather
than a useless value. Getting a "NoResultError" on that line of code
would make the problem obvious.

>     Paul> #3. Forgetting to return a value.
> 
> This is precisely the case that the default None return helps with.
> If the programmer sees "None" when popping up the dialog box during
> testing, it's a clear indication to go back and look at the function
> that generated the data the dialog box is displaying.

What if they notice a few weeks later that there are a bunch of None's
in their database, or that they sent out a mass-email with "None" here
and there in it? The point is, people would have a much greater chance
of catching these errors if an exception was raised instead of an
arbitrary default value being returned. The current behaviour is only
slightly more useful than functions returning the string "Naughty
naughty" by default.

The current behaviour is also inconsistent with sequences and maps. If I
say:

    x = [1,2,3][9]

an IndexError is raised. If I say:

    x = {'foo':'bar'}['quux']

a KeyError is raised. But if I say:

    def foo(int y):
        pass
    x = foo()

then x is set to 'None'. I think it would be better if an exception was
raised instead.

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