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/5029e4b9b92dbacdfc49867b7dcbee230ca782a8

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.