generator/coroutine terminology

Dave Angel davea at davea.name
Sat Mar 14 13:07:45 EDT 2015


On 03/14/2015 12:51 PM, Chris Angelico wrote:
> On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody <rustompmody at gmail.com> wrote:
>> As best as I can see python makes no distinction between such a foo and
>> the more usual function/methods that have no returns.
>> You can I can talk about these and distinguish them
>> Python has no clue about it.
>
> But what support is actually needed? Look, I can write functions that
> return values:
>
> def square(x):
>      return x*x
>
> four = square(2)
>
> and functions that don't:
>
> def save_to_file(fn):
>      with open(fn, "w") as f:
>          f.write(stuff)
>          f.write(more_stuff)
>
> save_to_file("/tmp/asdf")
>
> Who cares that the second one actually returns None and then ignores
> that? It's not returning anything, it's not using the function return
> value. This is, in effect, a procedure.
>
> How is Python worse off for doing things this way rather than having a
> true "function with no return value" or "procedure" concept?
>

And in C (at least the 80x86 implementations that I used) returns a 
value from a void function as well.  The value is an undefined int 
value, whatever the AX (EAX) register happened to contain.  The check 
that you didn't use such a value is made at compile time.

Further, in the original C definition, if you didn't define a return 
value, it was assumed to be int. And if you didn't define the arguments, 
they were assumed to be right.  In the "C calling convention," the 
caller was responsible for popping off the arguments, since the called 
function didn't necessarily have a clue how many there were.  Then 
later, for "efficiency reasons," they came up with the "Pascal calling 
convention," where the callee popped the arguments.  It perhaps was 
related to the fact that the 80x86 instruction set had the "return N" 
instruction which decremented the call stack pointer an additional 
amount, at the same time as doing the return.

I think the Python convention is exactly right for its other 
characteristics.  No declarations, no distinction.

-- 
DaveA



More information about the Python-list mailing list