Returning none

Jonathan Giddy jon at rdt.monash.edu.au
Wed Sep 1 01:28:38 EDT 1999


Greg Ewing <greg.ewing at compaq.com> writes:

>Tim Peters wrote:
>> 
>> You could invent a new internal NotARealObject type and
>> return a pointer to an object of that type, but then it gets messier.

>Not if you go about things the right way!

>The compiler knows whether the result of any given
>call gets used or not. Suppose it generates CALL_FUNCTION
>when the result is used, and a new opcode CALL_PROCEDURE
>when it doesn't.

>CALL_PROCEDURE checks that the result is NotARealObject 
>(I'll call it Void from now on) and raises an exception 
>otherwise. CALL_FUNCTION does the opposite.

This requires that we always use the result of a call to a real function,
even if we just assign it to a dummy variable.  And that means someone
will one day spend time trying to find where the dummy variable is used,
instead of instantly being aware that the function is only called for its
side effects.

For example, FileObject.close needs to be a function to return the exit
status of a popen process.  Hence, every file close will need to be
assigned (or used in some way).

Jon.




More information about the Python-list mailing list