This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: PEP 342 Generator enhancements
Type: Stage:
Components: Interpreter Core Versions: Python 2.5
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: pje Nosy List: georg.brandl, gvanrossum, mwh, pje
Priority: normal Keywords: patch

Created on 2005-06-18 23:08 by pje, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
yield.patch pje, 2005-06-18 23:18 PEP 342/343 generator enhancements
yield2.diff mwh, 2005-07-07 14:14 mwh's fixed version
Messages (13)
msg48478 - (view) Author: PJ Eby (pje) * (Python committer) Date: 2005-06-18 23:08
The attached patch implements code and test changes for:

* yield expressions
* bare yield (short for yield None)
* yield in try/finally
* generator.send(value) (send value into generator;
substituted for PEP 342's next(arg))
* generator.throw(typ[,val[,tb]]) (raise error in
* generator.close() (per PEP 343)
* GeneratorExit built-in exception type
* generator.__del__ (well, the C equivalent)
* All necessary mods to the compiler, parser module,
and Python 'compiler' package to support these changes.

It was necessary to change a small part of the eval
loop (well, the initialization, not the loop) and the
gc module's has_finalizer() logic in order to support a
C equivalent to __del__.  Specialists in these areas
should probably scrutinize this patch!

There is one additional implementation detail that was
not contemplated in either PEP. in order to prevent
used-up generators from retaining unnecessary
references to their frame's contents, I set the
generator's gi_frame member to None whenever the
generator finishes normally or with an error.  Thus, an
exhausted generator cannot be part of a cycle, and it
releases its frame object sooner than in previous
Python versions.  For generators used only in a direct
"for" loop, this makes no difference, but for
generators used with the iterator protocol (i.e.
"") from Python, this avoids stranding the
generator's frame in a traceback cycle.
msg48479 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2005-06-19 07:37
Logged In: YES 

Minor nit: on line 642, 'yield_stmt' should be changed to
msg48480 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-06-22 20:59
Logged In: YES 

Argh, I'd hoped you'd done with, too :)

Have you done any work on that yet?
msg48481 - (view) Author: PJ Eby (pje) * (Python committer) Date: 2005-06-23 23:07
Logged In: YES 

No, I haven't, and I never really planned to be the person
implementing "with".  Doesn't mean I might not end up doing
it eventually, but it's not currently in my plans.  I'm
going to have my hands full just updating PEP 342 (Guido has
asked me to take it over), and getting docs written to go
with this patch.  Between all that and my distutils-related
work, my pro-bono Python project time is booked up solid for
maybe the next 2 months or so.
msg48482 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-06-23 23:20
Logged In: YES 

Fair enough.  I want to use with statements in a presentation at 
EuroPython next week, so I've hacked together a truly horrible 
implementation that will do for now and will see about a real one some time 
msg48483 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2005-06-27 15:22
Logged In: YES 

(Removing 343 from the subject since all this is now in PEP

Playing with the code a bit, I notice that throw() doesn't
like string exceptions. That could cause some problems.

Also, I think the tb argument should be allowed to be None.

Otherwise, great! In a few hours you can check it in. :-)
msg48484 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-06-27 15:31
Logged In: YES 

Heh heh heh.
msg48485 - (view) Author: PJ Eby (pje) * (Python committer) Date: 2005-06-27 15:40
Logged In: YES 

I had hoped to be able to avoid dealing with string
exceptions, but I guess it makes sense that if somebody has
thrown one, it should be able to propagate. So I guess I'll
take care of that along with the rest.
msg48486 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2005-06-28 07:10
Logged In: YES 

Since I've accepted PEP 342+343 last night in my Europython
keynote, you can check this in now.
msg48487 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-07-07 14:14
Logged In: YES 

You missed an incref in gen_throw (symptom was

Fatal Python error: ../Objects/tupleobject.c:169 object at
0x4013807c has negative ref count -606348326

on exit after running test_generators).  New patch attached.
msg48488 - (view) Author: PJ Eby (pje) * (Python committer) Date: 2005-07-31 21:10
Logged In: YES 

mwh, is the only difference in your patch the addition of
the incref?
msg48489 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-08-01 10:10
Logged In: YES 

I think so, yes :)
msg48490 - (view) Author: PJ Eby (pje) * (Python committer) Date: 2005-08-02 00:48
Logged In: YES 

Checked in to CVS.  throw() still needs string support and
to allow None as the third argument, but I figure it's
better to get this thing into mainline CVS and address those
items separately.  I did include mwh's Py_INCREF fix, however.
Date User Action Args
2022-04-11 14:56:11adminsetgithub: 42099
2005-06-18 23:08:41pjecreate