Guido van Rossum wrote:
> Right. That was my point. Nick's worried about undecorated __context__
> because he wants to endow generators with a different default
> __context__. I say no to both proposals and the worries cancel each
> other out. EIBTI.
Works for me.
That makes the resolutions for the posted issues:
1. The slot name "__context__" will be used instead of "__with__"
2. The builtin name "context" is currently offlimits due to its ambiguity
3a. generator-iterators do NOT have a native context
3b. Use "contextmanager" as a builtin decorator to get generator-contexts
4. The __context__ slot will NOT be special cased
I'll add those into the PEP and reference this thread after Martin is done
with the SVN migration.
However, those resolutions bring up the following issues:
5 a. What exception is raised when EXPR does not have a __context__ method?
b. What about when the returned object is missing __enter__ or __exit__?
I suggest raising TypeError in both cases, for symmetry with for loops.
The slot check is made in C code, so I don't see any difficulty in raising
TypeError instead of AttributeError if the relevant slots aren't filled.
6 a. Should a generic "closing" context manager be provided?
b. If yes, should it be a builtin or in a "contexttools" module?
I'm not too worried about this one for the moment, and it could easily be
left out of the PEP itself. Of the sample managers, it seems the most
universally useful, though.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
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
