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

[Guido van Rossum]

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/)