[Python-Dev] Proposed resolutions for open PEP 343 issues

Nick Coghlan ncoghlan at gmail.com
Mon Oct 24 13:53:00 CEST 2005


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   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com


More information about the Python-Dev mailing list