Fix for issue #129 makes freezing time in threads impossible

I’m trying to test the interaction of several threads. In doing so, I need to freeze time, assert some things, tick, assert some more things, tick, etc. However, the fix for #129 appears to have made this impossible to do.

The problem is that I’m using time.time() in the code that I’m testing, and that code runs within multiple threads. As a result, the threading module appears in the stacktrace for my code that uses time.time(). So when _should_use_real_time inspects the stacktrace, it sees the threading frame and returns True, causing my code to get the real time. I had to do this to fix it:

def patched_freeze_time():
    f = freezegun.freeze_time()
    f.ignore = tuple(set(f.ignore) - {'threading'})
    return f

with patched_freeze_time() as frozen_time:
    # run tests

I understand the usefulness of ignoring threading by default, and I don’t want to regress #129, so I suggest a new freeze_time argument-with-default ignore_threading=True, and if it set to False then the threading module will not be included in ignore.

At alternative fix, if you feel that it’s truly necessary to always use real time in calls within the threading module itself, would be to hard-code exclude threading from the step where you patch modules’ imports, and then remove threading from the default ignores. In doing this, code calling time.time() (for example) within a running thread would still be affected by the frozen time, but time.time() calls within the threading module itself would not and would use real time.

[boxed]

I think we might need to think of more advanced/complex rules for looking at the stack. Not just saying “It’s threading!” but looking at why it’s in that module.

[westover]

Following