nit: Can this be named wait_for_pause?

How about block_until_paused?

Would it make sense to make paused be private, and call it after the yield? Or are there possible cases where the control never gets paused but we want to unpause it?

I'm not sure what you're asking here - read up on what @contextlib.contextmanager does to this function?

(One of the reasons I don't like decorators in Python is that they often change code in radical ways.)

I think this object makes sense with callable public methods and non-callable private fields and I'm not at all seeing what a private method would do?

After reading @contextlib.contextmanager, what I said doesn't make sense...

What I intended is something along these lines:

@contextlib.contextmanager
with self._condition:
  self._pause = True
self._block_until_paused()
yield
self._pause = False
self._condition.notify_all()

Then anytime we have

with control.pause()
  #Do some stuff

We know that control is actually paused without needing to call block_until_paused

That would be really bad because the way this object is used is

with control.pause():
  <set in motion the behavior under test that would lead to the system under test being paused>
  <either call control.block_until_paused or don't>
  <maybe do some other stuff>

. With the semantics you suggest, that code would have to be changed to

<set in motion the behavior under test that would lead to the system under test being paused>
with control.pause():
  <either call control.block_until_paused or don't>
  <maybe do some other stuff>

and that would create a race condition in which the system under test could pass the control point (where it calls control.control()) before the test system enters the control.pause() context.

Concretely, look at the way this is used in expiration tests: we say that the service-side application should pause, then we invoke the RPC, then we chill out until we see the RPC time out, and then we leave the pause context and allow the service-side application to return from its RPC method handler. With the behavior you propose, the test would have to invoke the RPC before entering the pause context and the service-side application could finish servicing the RPC method before the test enters the pause context.

Right?

Makes sense. Thanks for the context.