Returning none

[Greg Ewing]

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.

> is it also OK for f() to return nothing in the statement
> 
>     f(), g(), h()
> 
> ?  You must allow that else break existing code,

We've *already* broken existing code, since we're now 
disallowing any unadorned expression whose value isn't 
Void. 

Strictly speaking, in that example f() would not be
allowed to return Void, since it's being called as a
function. But, that whole statement could be statically 
rejected by the compiler, since it always evaluates to
a tuple.

Moreover, the compiler could (and would almost have to)
reject any unadorned expression that wasn't a call
or something trivially equivalent (such as a call
surrounded by parentheses).

In summary, a Void object *could* have been incorporated
into the scheme of things and made to Do The Right Thing.
But then it would have been a different language.

Maybe in Python 2?

Greg