Returning none

[Quinn Dunkan]

On Thu, 26 Aug 1999 16:15:57 GMT, Jeff Bauer <jbauer at rubic.com> wrote:
>Arguably, it may not be the best coding style, but I've 
>gotten used to functions returning None, if not otherwise
>specified.  If your proposal could be guaranteed to 
>generate a compile-time error (could it?), it might
>encounter less resistance, but I still wouldn't be
>very enthusiastic about the idea.  I can appreciate
>the issue you're addressing, though.
>
>Paul Prescod wrote:
>> 
>> I think it would be more pythonish if this would return a runtime 
>> (or even compiletime) error:
>> 
>> def foo():
>>         a=5
>> 
>> b=foo()
>> 
>> It shouldn't just return None. That's a source of errors.
>> This is obviously an incompatible change so I propose it 
>> for Python 2.

I agree with that Jeff that implicitly returning None is too handy, but I
think this could be solved by putting it in PyLint and having PyLidnt more
integrated with the distribution, or building some sort of compile/runtime
warning system into python (like gcc -Wall or perl -w) that can be arbitrarily
verbose.

Perhaps it would be possible to have python send all -Wxxx switches to
something like PyLint before compiling.  We already have -t, this would just
be extending that idea further.