Returning none

C.Laurence Gonsalves clgonsal at keeshah.penguinpowered.com
Thu Sep 2 19:36:27 EDT 1999


On 1 Sep 1999 05:28:38 GMT, Jonathan Giddy <jon at rdt.monash.edu.au> wrote:
> Greg Ewing <greg.ewing at compaq.com> writes:
> >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).

That's why I suggested the addition of a new type of statement, similar
to 'EVAL' statements in Modula-3. In Modula 3, a function call is not a
legal statement (but a procedure call is). If you reall want to call a
function though without getting the result you would say:

    EVAL MyFunctionWithAUselessResult();

Since 'eval' is already used for something in Python, I'd suggested that
the Python equivalent could be called 'discard'.

    discard inFile.close()

-- 
  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 mailing list