Hi Damian, To answer your first question, we ran into the trouble when mocking time.time(). This came up for us, as type(time.time) is 'builtin_function_or_method', which is the same as type(open) -> 'builtin_function_or_method'. We also updated your adaptation to our patch so that no code is repeated. This should make the function cleaner and more readable. This new code can be found at: https://github.com/jacthinman/Tor-Stem/blob/mocking/test/mocking.py Best, -Erik & Megan On Wed, Jun 13, 2012 at 2:21 AM, Damian Johnson <atagar@torproject.org>wrote:
Hi Megan, thanks for the patch! What is an example of a standard library function with a builtin type? I'd like to exercise the use case that has been causing you trouble.
This change has a couple issues, for instance it treats anything with the same name as a builtin like a builtin. It also calls setattr() on standard library functions if you try to mock it a second time.
I've pushed an adaptation of your change to the 'mocking' branch of my personal repository... git://git.torproject.org/user/atagar/stem.git
change...
https://gitweb.torproject.org/user/atagar/stem.git/commitdiff/5029e4b9b92dba...
It shouldn't have the issues that I mentioned, though some remaining bits of the change confuse me. As you've found the mocking code is pretty tricky so I won't be able to make sense of it until I see what was breaking.
Thanks! -Damian
PS. Very nice commit message on b8b7c22. It helped me a lot in making sense of the change - thanks for that.