Added Q&A about "return".
This commit is contained in:
parent
db019e19e7
commit
de1820491f
18
pep-0255.txt
18
pep-0255.txt
|
@ -310,6 +310,24 @@ Q & A
|
||||||
determine potential suspension points at compile-time, and a new
|
determine potential suspension points at compile-time, and a new
|
||||||
keyword makes that easy.
|
keyword makes that easy.
|
||||||
|
|
||||||
|
Q. Why allow "return" at all? Why not force termination to be spelled
|
||||||
|
"raise StopIteration"?
|
||||||
|
|
||||||
|
A. The mechanics of StopIteration are low-level details, much like the
|
||||||
|
mechanics of IndexError in Python 2.1: the implementation needs to
|
||||||
|
do *something* well-defined under the covers, and Python exposes
|
||||||
|
these mechanisms for advanced users. That's not an argument for
|
||||||
|
forcing everyone to work at that level, though. "return" means "I'm
|
||||||
|
done" in any kind of function, and that's easy to explain and to use.
|
||||||
|
|
||||||
|
Q. Then why not allow an expression on "return" too?
|
||||||
|
|
||||||
|
A. Perhaps we will someday. In Icon, "return expr" means both "I'm
|
||||||
|
done", and "but I have one final useful value to return too, and
|
||||||
|
this is it". At the start, and in the absence of compelling uses
|
||||||
|
for "return expr", it's simply cleaner to use "yield" exclusively
|
||||||
|
for delivering values.
|
||||||
|
|
||||||
|
|
||||||
Reference Implementation
|
Reference Implementation
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue