Nick Coghlan ncogh...@gmail.com added the comment:
Switched to strings in r86879.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10220
___
Nick Coghlan ncogh...@gmail.com added the comment:
Temporarily reopening to remind me to switch from using integer constants to
strings (which are much friendlier for debugging purposes).
--
status: closed - open
___
Python tracker
Guido van Rossum gu...@python.org added the comment:
Yes please.
On Mon, Nov 22, 2010 at 7:44 AM, Nick Coghlan rep...@bugs.python.org wrote:
Nick Coghlan ncogh...@gmail.com added the comment:
Temporarily reopening to remind me to switch from using integer constants to
strings (which are
Rodolpho Eckhardt r...@rhe.vg added the comment:
This patch adds the getgeneratorstate function and related tests.
--
keywords: +patch
nosy: +Rodolpho.Eckhardt
Added file: http://bugs.python.org/file19705/getgeneratorstate.patch
___
Python tracker
Éric Araujo mer...@netwok.org added the comment:
Looks good, modulo two nitpicks:
1) Using literals for constants would avoid a lookup and call of range.
2) Please remove four leading spaces in your docstring.
--
nosy: +eric.araujo
___
Python
Changes by Rodrigo Bernardo Pimentel r...@isnomore.net:
--
nosy: +rbp
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10220
___
___
Python-bugs-list
Rodolpho Eckhardt r...@rhe.vg added the comment:
Done, thank you!
Second version attached.
--
Added file: http://bugs.python.org/file19712/getgeneratorstate_v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10220
Éric Araujo mer...@netwok.org added the comment:
Nice. Now you can sit back, relax and wait for Nick to commit the patch or
make further comments.
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
I'll actually go with version 1 of the patch as far as the variable
initialisation goes. Yes, it is fractionally slower, but you get a maintenance
gain from the fact that the enum values are guaranteed to be orthogonal, and
this is clearly
Nick Coghlan ncogh...@gmail.com added the comment:
Committed in r86633.
I added the missing docs changes, and tweaked the tests a little bit:
- added a helper method to retrieve the generator state in the test case
- this allowed test_running to be simplified a bit
- added an explicit test for
Changes by Zbyszek Szmek zbys...@in.waw.pl:
--
nosy: +zbysz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10220
___
___
Python-bugs-list mailing
New submission from Nick Coghlan ncogh...@gmail.com:
Generators can be in four different states that may be relevant to framework
code making use of them (especially as coroutines). This state is all currently
available from Python code, but is rather obscure and could be made readable.
The
Antoine Pitrou pit...@free.fr added the comment:
Is it CPython-specific?
Does currently executing also include currently closing?
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10220
Nick Coghlan ncogh...@gmail.com added the comment:
On Thu, Oct 28, 2010 at 10:55 PM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou pit...@free.fr added the comment:
Is it CPython-specific?
The states are not CPython-specific (they're logical states of the
underlying
Guido van Rossum gu...@python.org added the comment:
I could imagine separating the state into two parts:
- a three-valued enum distinguishing created, active, or exhausted
- a bool (only relevant in the active state) whether it is currently running or
suspended
The latter is just
Nick Coghlan ncogh...@gmail.com added the comment:
So something like:
GEN_CREATED, GEN_ACTIVE, GEN_CLOSED = range(3)
def getgeneratorstate(g):
Get current state of a generator-iterator.
Possible states are:
GEN_CREATED: Created, waiting to start execution
GEN_ACTIVE: Currently
Guido van Rossum gu...@python.org added the comment:
I take it back. The 4-value state looks better.
My initial hesitance was that if you ever see GEN_RUNNING you are
probably already in trouble, since you can't call send, next, throw or
even close on a running generator (they all throw
Nick Coghlan ncogh...@gmail.com added the comment:
Indeed, the minimal lifecycles are:
GEN_CREATED-GEN_CLOSED (exception thrown in before the generator was even
started)
GEN_CREATED-GEN_RUNNING-GEN_CLOSED (initial next() with internal logic that
skips all yields)
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10220
___
___
Python-bugs-list
19 matches
Mail list logo
