[Python-Dev] Why are contexts also managers? (wasr45544 -peps/trunk/pep-0343.txt)
Barry Scott
barry at barrys-emacs.org
Tue Apr 25 00:52:05 CEST 2006
On Apr 24, 2006, at 03:49, Nick Coghlan wrote:
> Just van Rossum wrote:
>> Baptiste Carvello wrote:
>>
>>> Terry Reedy a écrit :
>>>> So I propose that the context maker be called just that: 'context
>>>> maker'. That should pretty clearly not be the context that manages
>>>> the block execution.
>>>>
>>> +1 for context maker. In fact, after reading the begining of the
>>> thread, I came up with the very same idea.
>>
>> Or maybe "context factory"?
Yes its a factory. That is traditionally that you call a function
that makes objects isn't it?
> That would be fine if we used __call__ to retrieve the context
> manager - but
> "factory" is too tightly bound to "factory function" in my mind.
__call__ may or may not implement a factory, that is up to my design
to decide.
__context__ is always a factory because that is the interface that
"with" mandates.
factory function is one way to implement a factory so yes its tightly
bound,
but that not a reason to reject factory.
From what I've read on this list this is all there is to it:
with EXPR:
block
with needs a context. If the EXPR object has a __context__ method
it is a factory that will make a suitable context for the EXPR object
otherwise EXPR is the context.
that context must have __enter__ and __exit__ methods to operate
the with protocol.
I haven't learn about decorators so I've no comment on why you need
them as well as the special method names. But the docs should tell
me why.
Barry
More information about the Python-Dev
mailing list