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 <[email protected]>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. >
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
