[Python-Dev] Proposed resolutions for open PEP 343 issues
Guido van Rossum
guido at python.org
Sat Oct 22 19:22:56 CEST 2005
On 10/22/05, Nick Coghlan <ncoghlan at iinet.net.au> wrote:
> I'm still looking for more feedback on the issues raised in the last update of
> PEP 343. There hasn't been much direct feedback so far, but I've rephrased and
> suggested resolutions for the outstanding issues based on what feedback I have
> received, and my own thoughts over the last week of so.
Thanks for bringing this up again. It's been at the back of my mind,
but hasn't had much of a chance to come to the front lately...
> For those simply skimming, my proposed issue resolutions are:
>
> 1. Use the slot name "__context__" instead of "__with__"
+1
> 2. Reserve the builtin name "context" for future use as described below
+0.5. I don't think we'll need that built-in, but I do think that the
term "context" is too overloaded to start using it for anything in
particular.
> 3a. Give generator-iterators a native context that invokes self.close()
I'll have to think about this one more, and I don't have time for that
right now.
> 3b. Use "contextmanager" as a builtin decorator to get generator-contexts
+1
> 4. Special case the __context__ slot to avoid the need to decorate it
-1. I expect that we'll also see generator *functions* (not methods)
as context managers. The functions need the decorator. For consistency
the methods should also be decorated explicitly.
For example, while I'm now okay (at the +0.5 level) with having files
automatically behave like context managers, one could still write an
explicit context manager 'opening':
@contextmanager
def opening(filename):
f = open(filename)
try:
yield f
finally:
f.close()
Compare to
class FileLike:
def __init__(self, ...): ...
def close(self): ...
@contextmanager
def __context__(self):
try:
yield self
finally:
self.close()
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list