On 03/14/2015 12:51 PM, Chris Angelico wrote:
On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody <rustompm...@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
--
https://mail.python.org/mailman/listinfo/python-list
