[Python-Dev] Why are contexts also managers? (wasr45544 -peps/trunk/pep-0343.txt) (original) (raw)

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