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

[Guido van Rossum]

On 10/24/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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

+1

> 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.

Why are you so keen on TypeError? I find AttributeError totally
appropriate. I don't see symmetry with for-loops as a valuable
property here. AttributeError and TypeError are often interchangeable
anyway.

>    6 a. Should a generic "closing" context manager be provided?

No. Let's provide the minimal mechanisms FIRST.

>      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.

Let's leave some examples just be examples.

I think I'm leaning towards adding __context__ to locks (all types
defined in tread or threading, including condition variables), files,
and decimal.Context, and leave it at that.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)