Returning none

[Alexander Williams]

On Sat, 28 Aug 1999 22:55:59 GMT, C.Laurence Gonsalves
<clgonsal at keeshah.penguinpowered.com> wrote:

>should return None though. They should return *nothing-at-all*. The fact
>that some value (None) is returned in these cases is a source of errors,
>because function writers sometimes forget to return a value, and
>function callers sometimes try to get a value from something that isn't
>intended to return anything.

Python is not a Bondage and Discipline language; with that nature
comes a very important freedom, the Freedom To Make Mistakes.  Yes,
you can write code that doesn't run or is broken in Python.  Oddly,
however, this doesn't differ from any of the other languages which are
heavily into B&D, its just that Those Others make you jump through
hoops and learn to tie ropes just for the opportunity to make
mistakes.

I think you're critically overestimating the enormity of this
'problem,' in fact I don't think its a problem at all.  The amount of
flexibility that comes as a result for various coding styles seriously
overshadows the fact that, yes, someone can shoot themselves in the
foot with it.  By that measure, we should remove classes from the
language since they can be a source of errors.  Reducido ad absurdiam.

>There are several ways to have the language reduce these kinds of
>errors. I've suggested at least three possibilities. Some of these

Reducing these kinds of 'errors' isn't the function of a language.  If
a language construct can be misused, its not the fault of the language
design, its the fault of a programmer.  Rather than misplace the
effort of 'fixing' the problem of Guido's head, I feel, like several
others posting to this thread, that its far more a cause to put in
another check for PyLint.  If the programmer chooses not to PyLint his
code, that's his choice.  If he chooses to use a construct that can be
dangerous, that's his choice, too.

I have only encountered this kind of error a few times in the years
I've been programming in Python.  This probably stems from the fact I
tend to program in a sort of 'side-effectless style' which Python
encourages when dealing with the imperitive programming style (as
differing from the object-oriented style one gets into which hinges on
self-encapsulated objects and instances).  That a language encourages
one style of programming at the expense of another is hardly reason to
change the language, /especially/ if both idioms are perfectly valid
means within the language.

-- 
Alexander Williams (thantos at gw.total-web.net)
"In the end ... Oblivion Always Wins."