clgonsal at keeshah.penguinpowered.com
Fri Aug 27 03:23:42 EDT 1999
On Thu, 26 Aug 1999 17:07:43 GMT, Kris J. Zaragoza
<kzaragoza at mediaone.net> wrote:
> On Thu, 26 Aug 1999 14:33:40 GMT, Paul Prescod <paul at prescod.net> wrote:
> >I think it would be more pythonish if this would return a runtime (or
> >even compiletime) error:
> >def foo():
> > a=5
> >It shouldn't just return None. That's a source of errors.
> The question here is, where is the error?
> Now when the call is made, you need to make a determination as to
> whether the calling line is in error, or the function itself is in
> error. With your example, it could be either. The author of the
> function may have erred in neglecting to insert a return statement at
> the end of the function. If, on the other hand, the function does not
> intend to return any values, then the author of the calling line made
> the error in simply assuming that it would.
The same could be said about many things that Python currently does
treat as errors. If I pass one parameter to a function that wants two,
is it my fault for leaving out a parameter, or the function's fault for
requiring it. Either way, Python assumes the caller is at fault. If I
wrote the function, and it's really the function that's at fault, I'll
realize that its definition should change, not the call.
> I tend to like Python's current way of handling things. If a function
> does not explicitly return a value, None is returned instead. It's a
> clean solution to an otherwise intractable problem.
It isn't intractable, unless you're trying to figure it out at compile
> How do you propose fixing this in Python 2? Would you enforce the
> separation of blocks that do and don't return values? Would you
> include some sort of pragmas that tell the compiler and runtime that a
> value is not to be returned? Other ideas? (Personally, I wouldn't
> mind if this stayed as is. I just read the documentation or doc
> string to see if a given function is meant to return a value.)
I frequently run into this same problem. Something I often do is write
functions that build up a result, and then I forget to return it. ie:
# Yes, I know there's a much easier way to do this. It's just for
def seqToString( seq ):
result = '['
result = result + repr(seq)
for item in seq[1:]:
result = result + ', ' + repr(item)
result = result + ']'
It's quite easy to go to all of the trouble of creating a result, and
then forget to return it. Later, when I call the above function, I get
back "None". If it instead raised an exception when I called it and
attempted to get a result from it, then these errors would be much
easier to catch.
Personally, I think falling out of functions and expecting None to be
implicitly returned is a very Perl-ish thing to do... Why don't we add
$_ to Python as well? 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.
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. There would still
have to be a runtime error for cases where someone tried to get a result
from a procedure, but cases like the above example could be caught at
compile-time. (The above, being a function, must return a value.
Procedures would have to defined in some other way, like using some new
keyword "proc" in place of "def")
C. Laurence Gonsalves "Any sufficiently advanced
clgonsal at kami.com technology is indistinguishable
http://www.cryogen.com/clgonsal/ from magic." -- Arthur C. Clarke
More information about the Python-list