Karol Kuczmarski

Sorry, I had some other stuff to do over the weekend :) Nevertheless, I checked my hypothesis and it seems nothing really changed, except for error changing to failure which...

Okay, I'm confused now. I scoured the code of mocktest's `TestCase` and found out that it doesn't really do anything in `run` method which would be able to produce both...

Not sure whether this is actually good idea. Putting __arbitrary__ into class definition would require importing pyqcy into the module being tested which doesn't look like good idea at all....

This is the issue that I have actually faced myself and found quite cumbersome indeed. I'd probably like something similar to how py.test handles its funcargs: ``` python def pytest_funcarg__foo(request):...

It could work. But `length` is important parameter when it comes to implementing the all-too-awesome "shrink" operation, so I need to consider how any change here would affect that future...

I'm not sure if there is an obvious place for it in the operator precedence order. And if there isn't, then it'd be common to use parentheses for disambiguation, which...

Curious. I'd probably have to test it myself but since 44 is close to the expected value for sum of ten random integers from {0..10}, I'd suspect it's because MockTransaction...

That's ok :) As for `MockTransaction`, the problem with integrating it neatly is that `mocktest.TestCase` relies on `setUp` and `tearDown` for managing the `MockTransaction`. These are called once for every...

Definitely an option, yes. I'll need to weight pros and cons of each solution here.