No, you also need to consider threading, async programming, and if we want to truly simulate the language feature we can’t assume the object can be mutated by adding an attribute. Either way, I was wrong, see the other thread I linked above for decorators that solve all of that, but it for sure isn’t simple.
Ah cool. Did not notice your link to a prior, better-rounded solution.
Making it a mixin class instead of a decorator would solve the problem of mutating a class by the way.
Yeah, for sure. If this never becomes a language feature, that’s a valid approach. Although the true encapsulation provided by the decorator pattern implementer in the other thread is ofcourse slightly safer for uncareful users would do something like explore __dict__.
How about “contextual object” ?
For me, the “context” is the fact that in the indented block, a file is open (for example), it’s not open elsewhere, so accessing it is specific to that indented context. As Ethan pointed out :
If I understand the proposed interface correctly, a “context manager” generates a “contextual object” 
1 Like
What about withable?
Enterable?
1 Like
Other languages call this “disposable”, because it’s considered that the purpose of the analogous construct is to acquire and then dispose of a resource. Although the corresponding interface might not be just the ability to power a with-block-equivalent (sometimes called “using”, etc.); it might e.g. also include an explicit disposal method (analogous to the close method of files).
1 Like