>> I can't see all that much use for GeneratorExit in code that needs to >> be compatible with 2.4, since the rest of the machinery that makes >> exception handling around yield feasible doesn't exist. > > I agree entirely - my goal is to make sure it stays that way. > > The kind of code I'm talking about would be an *existing* Python 2.4 generator > that happens to do something like: > > def gen(tasks): > """yield the results of a bunch of task functions""" > for task in tasks: > try: > yield (task, task()) > except Exception, ex: > yield ExceptionOccurred(task, ex) > > > If you run such a generator on Python 2.5, but don't run it to completion > before it is garbage collected, you will get an error message printed on > stderr saying that an exception was ignored when this generator was cleaned > up. If you use the new PEP 342 features to try to explicitly close it before > it is garbage collected, you'll get the exception directly. > > The culprit is the RuntimeError raised when the generator's close() method > gets upset because the generator swallowed GeneratorExit. > > If GeneratorExit inherits directly from BaseException, such unexpected > behaviour won't happen - the only way for an existing generator to break is if > it contained a bare except clause, and that code was *already* dubious (e.g. > it probably swallowed KeyboardInterrupt). > > I don't have any actual live examples of a generator with a broad exception > clause like the one above, but toy generators like the one above are legal in > 2.4 and result in spurious errors with current SVN.
I can't say that I care enough about this hypothetical inter-version flimflam to warrant mucking-up the otherwise useful distinction between Exception and BaseException. special-cases-aren't-special-enough ... Raymond _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
