Abstract

This PEP proposes to enhance generators by providing mechanisms forraising exceptions and sharing data with running generators.

Status

This PEP is withdrawn. The exception raising mechanism was extendedand subsumed intoPEP 343. The attribute passing capabilitynever built a following, did not have a clear implementation,and did not have a clean way for the running generator to accessits own namespace.

Rationale

Currently, only class based iterators can provide attributes andexception handling. However, class based iterators are harder towrite, less compact, less readable, and slower. A better solutionis to enable these capabilities for generators.

Enabling attribute assignments allows data to be passed to and fromrunning generators. The approach of sharing data using attributespervades Python. Other approaches exist but are somewhat hackishin comparison.

Another evolutionary step is to add a generator method to allowexceptions to be passed to a generator. Currently, there is noclean method for triggering exceptions from outside the generator.Also, generator exception passing helps mitigate the try/finallyprohibition for generators. The need is especially acute forgenerators needing to flush buffers or close resources upon termination.

The two proposals are backwards compatible and require no newkeywords. They are being recommended for Python version 2.5.

Specification for Generator Attributes

Essentially, the proposal is to emulate attribute writing for classes.The only wrinkle is that generators lack a way to refer to instances ofthemselves. So, the proposal is to provide a function for discoveringthe reference. For example:

defmygen(filename):self=sys.get_generator()myfile=open(filename)forlineinmyfile:iflen(line)<10:continueself.pos=myfile.tell()yieldline.upper()g=mygen('sample.txt')line1=g.next()print'Position',g.pos

Uses for generator attributes include:

1. Providing generator clients with extra information (as shownabove).
2. Externally setting control flags governing generator operation(possibly telling a generator when to step in or step overdata groups).
3. Writing lazy consumers with complex execution states(an arithmetic encoder output stream for example).
4. Writing co-routines (as demonstrated in Dr. Mertz’s articles[1]).

The control flow of ‘yield’ and ‘next’ is unchanged by thisproposal. The only change is that data can passed to and from thegenerator. Most of the underlying machinery is already in place,only the access function needs to be added.

Specification for Generator Exception Passing

Add a.throw(exception) method to the generator interface:

deflogger():start=time.time()log=[]try:whileTrue:log.append(time.time()-start)yieldlog[-1]exceptWriteLog:writelog(log)g=logger()foriin[10,20,40,80,160]:testsuite(i)g.next()g.throw(WriteLog)

There is no existing work-around for triggering an exceptioninside a generator. It is the only case in Python where activecode cannot be excepted to or through.

Generator exception passing also helps address an intrinsiclimitation on generators, the prohibition against their usingtry/finally to trigger clean-up code (PEP 255).

Note A: The name of the throw method was selected for severalreasons. Raise is a keyword and so cannot be used as a methodname. Unlike raise which immediately raises an exception from thecurrent execution point, throw will first return to the generatorand then raise the exception. The word throw is suggestive ofputting the exception in another location. The word throw isalready associated with exceptions in other languages.

Alternative method names were considered:resolve(),signal(),genraise(),raiseinto(), andflush(). None of these fit as wellasthrow().

Note B: To keep thethrow() syntax simple only the instanceversion of the raise syntax would be supported (no variants for“raisestring” or “raiseclass,instance”).

Callingg.throw(instance) would correspond to writingraiseinstance immediately after the most recent yield.

References

Copyright

This document has been placed in the public domain.