[Python-Dev] Proposed resolutions for open PEP 343 issues
Guido van Rossum
guido at python.org
Mon Oct 24 16:47:47 CEST 2005
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
> 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
> 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/)
More information about the Python-Dev