This page is dedicated to the public discussion of [http://www.python.org/peps/pep-0343.html PEP 343]: Anonymous Block Redux and Generator Enhancements.

I think this is a good one; I hope people agree. Its acceptance will obsolete about 4 other PEPs! (A sign that it fulfills a need and that the proposed solution is powerful.)

Please read the PEP; then add your comments here. Please sign your comments with your name. ["GvR"] (Guido van Rossum)

I feel like PEP 343 and PEP 342 work together in some important way, but it's not clear what that is. Does one depend on the other? What kind of things are possible if both are accepted (vs. just one of them)? I think this is important to understanding where PEP 343 is leading; some discussion of this would be appreciated. -- IanBicking

• No, they are quite independent. PEP 342 is for making generators into real coroutines. Maybe thow() can help a tiny bit there but I think it's not essential. PEP 342 adds argument-less yield to PEP 343 which is a very minor improvement (no "yield None"). ["GvR"]

The optional extension mentioned would not need to lead to mistakes if the exit call would distinguish between 'with X' and 'with X as Y'. -- Eric Nieuwland

• Please explain. ["GvR"]

next_throw() is easier to grep with next(). Niki Spahiev

I've tuned out the recent conversation on these PEPs quite religiously, because I never thought they would result in anything even vaguely useful. Fortunately, I was dead wrong. PEP-343 is simple, elegant, and feels very Pythonic to me. I need to catch up now and think through the implications and corner-cases, but I can give a provisional +1 to the concept. Thanks to all those that didn't tune out and worked to get us to this point. -- Kevin Jacobs

A few immediate comments:

1. Is g.throw(...) supposed to let you raise exceptions in other threads (by having g catch the exception you throw it, then raise its own exception for its caller)? The PEP should be clear about this. It would be great if the answer is yes and if that's the case, objects like queues and sockets should be turned into generators to permit cross-thread signalling using generator exceptions. But I had the impression that this would be difficult in CPython.
   • This is not the intention at all. I don't see how it could work (you'd need some way to get the other thread's attention). ["GvR"]
2. I thought some of the original motivation of PEP 310 was to lessen the pain of giving up the idiom of expecting files to be closed when their last reference goes away. So if 343 no longer guarantees that the exit method will be run when the "with" statement finishes, it's lost some of its main motivating functionality. I wonder if having a more serious treatment of block scope, so that destructors are guaranteed to be called when a scope exits (by falling through or via an exception), would also take care of this issue.
   • Where did you read that the exit method isn't guaranteed to be called upon exit from the with statement? The translation explicitly calls it! Read again. You may be confused with g.close(). That's only relevant when you use a for-loop without an explicit with-statement. ["GvR"]

There was some good discussion on clpy a while ago that I'll try to locate, and add some more comments during the weekend. --Paul Rubin (phr)