PEP 219: Fix grammatical mistakes (#900)
This commit is contained in:
parent
7b72f683be
commit
56e3d578dc
|
@ -25,7 +25,7 @@ implementation, they do not regard Stackless as a reference
|
|||
implementation. Stackless (with an extension module) implements
|
||||
continuations, and from continuations one can implement
|
||||
coroutines, microthreads (as has been done by Will Ware [2]_) and
|
||||
generators. But in more that a year, no one has found any other
|
||||
generators. But in more than a year, no one has found any other
|
||||
productive use of continuations, so there seems to be no demand
|
||||
for their support.
|
||||
|
||||
|
@ -54,7 +54,7 @@ simple case of coroutines.)
|
|||
Real threads allocate a full-sized stack for each thread of
|
||||
control, and this is the major source of overhead. However,
|
||||
coroutines and microthreads can be implemented in Python in a way
|
||||
that involves almost no overhead. This PEP, therefor, offers a
|
||||
that involves almost no overhead. This PEP, therefore, offers a
|
||||
way for making Python able to realistically manage thousands of
|
||||
separate "threads" of activity (vs. today's limit of perhaps dozens
|
||||
of separate threads of activity).
|
||||
|
@ -158,7 +158,7 @@ itself.
|
|||
|
||||
Most recursions of the interpreter are not this complex, but
|
||||
fairly frequently, some "post" operations are required. Stackless
|
||||
does not fix these situations because of amount of code changes
|
||||
does not fix these situations because of the amount of code changes
|
||||
required. Instead, Stackless prohibits transfers out of a nested
|
||||
interpreter. While not ideal (and sometimes puzzling), this
|
||||
limitation is hardly crippling.
|
||||
|
|
Loading…
Reference in New Issue