PEP 288: Generator Attributes
Bengt Richter
bokr at oz.net
Wed Dec 4 01:22:20 EST 2002
More information about the Python-list mailing list
Wed Dec 4 01:22:20 EST 2002
- Previous message (by thread): PEP 288: Generator Attributes
- Next message (by thread): PEP 288: Generator Attributes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 4 Dec 2002 00:08:39 GMT, bokr at oz.net (Bengt Richter) wrote: [...] > >Note that a generator could now be also used with map, reduce, and filter as functions >as well as sequence sources. E.g., IWT you could write compile as a string filter. > And also note that the function associated with the generator object could be recursive, even involving other recursive functions recursively calling back! This would be a consequence of changing yield to act according to its dynamic position in execution. I.e., yield becomes like raising an exception without unwinding the stack, and instead tracing it down to the first[1] generator __call__ frame. [1] Hm... I wonder if a targeted yield that could find a particular generator __call__ frame would be of use. You could specify an optional name in the call to the generator factory method, which would default to the name of the function instance passed to it. Then you could potentially suspend a context with one or more internal generators running. This could be nice for coroutine multitasking, to yield back to a scheduler without having to give up the state of active generators within tasks. You'd need syntax to use it, e.g., maybe yield some_value as 'name_string' # re-using 'as' e.g., alluding to foo function-result in "as foo" when returning to the generator __call__ context that made the primary call to foo. Regards, Bengt Richter
- Previous message (by thread): PEP 288: Generator Attributes
- Next message (by thread): PEP 288: Generator Attributes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list