Am 22.07.2014 23:13, schrieb Guido van Rossum:
I don't feel competent to contribute to the kind of test framework
you're proposing, because I wouldn't be using it myself. I think that
the right progression should be something like this:
1. You discover that you have a similar need in several tests and write
some support code.
2. You refactor that into a small framework that solves the problem
well for most of your current and some of your future use cases.
3. You clean it up and release it on pypy and solicit feedback.
4. You and others who use it iterate a few times.
5. Eventually you suggest adding it to the stdlib -- or perhaps to the
tulip project (since I assume your framework might have dependencies on
Twisted and/or Trollius, which isn't really appropriate for the stdlib).
It seems you're currently in stage 2, but you seem to be asking to jump
straight to stage 5?
No, I'm still at 1.5;) Thinking about it, my needs resolve around:
A. Helpers for code that wants to run on both asyncio and Twisted,
possibly Tornado.
B. A unittest.TestCase and test driver with builtin support for asyncio
futures / coroutine decorators
Cleary A. doesn't make sense in tulip, trollius or stdlib. I do have
some working (trivial) code here I could split out into a separate package.
And B. could then reside in such a package as well, even though it's
asyncio specific.
So I guess what I am after is "six for asyncio/Twisted" ;)
/Tobias
--
--Guido van Rossum (python.org/~guido <http://python.org/~guido>)
