The name TimedFailure sucks. I did not modify Timeout because the isinstance() check is a performance hit.
Instead of finding a better name we could also streamline the API by adding a Success class (which would be almost identical to Timeout) and a Failure class. Both would accept an optional delay parameter. For example:
env.success('foo')# delay defaults to zeroenv.success('foo',delay=2)env.success('foo',2)env.failure(ValueError('spam'))# also delay of zero per defaultenv.failure(ValueError('spam'),delay=2)
Sounds confusing, seems like you want to succeed or fail the whole environment. As mentioned in issue #54 if we would stop scheduling timeouts during init we can create timeouts normally using any delay and succeed or fail them manually.
Still I'm beginning to think that calling env.schedule in init is actually an unwanted side-effect. I think it would be better to not have anything schedule anything if you just create it, but only if you create it through the environment shortcuts. That would also give a little distinction between x = Timeout(env, 2) and env.timeout(2).
Thinking further in that direction, you could remove succeed, fail and trigger from all events and offer them as methods of the environment, e.g.: env.succeed(event). That would also solve the visibility of schedule, because nobody needs access to it anymore.
Please don't say our coding conventions, you are the only one enforcing them. I've always said that I've objections against some flake8 warnings and explained why I think so. You could have easily disabled on the offending whitespace warnings as a compromise or at least try to explain the benefits.
Anyhow, I will now stop spending time discussing non-technical flake8 whitespace stuff and let you have it your way.