Guido van Rossum wrote:
On 10/16/05, Nick Coghlan <ncoghlan@iinet.net.au> wrote: I hope you reverted the status to "Proposed"...
I hadn't, but I've now fixed that in CVS (both in the PEP and the PEP index), and added some text into the PEP saying why it was reverted to Draft.
On the latter: I think it shouldn't; I don't like this kind of magic. I'll have to read it before I can comment on the rest.
I don't particularly like treating __with__ specially either, but I'm not sure I like the alternative. The alternative is that we'd never be able to safely define a __with__ method directly on generators - the reason is that we would want a "def __with__" where the @context decorator has been forgotten to trigger a TypeError when it is used. If generator-iterators were to provide a context manager to automatically invoke close(), then leaving out "@context" would result in a very obscure bug (as g.close() would be used to finish the context, instead of g.next() or g.throw()). On the other hand, if the context decorator is invoked automatically when a generator function is supplied to populate the __with__ slot, then using a generator to define a __with__ method will "just work", instead of "only works if you also apply the context decorator" Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com