> The way the os module seems to reference posix, I don't believe we will run
> into any platform dependencies...
Ahhh, gotcha. My understanding of the usage was backwards (I thought
that you planned to provide posix as the new argument). In that case
looks good to merge, will do tomorrow morning
The way the os module seems to reference posix, I don't believe we will run
into any platform dependencies. Since os determines what environment it is
in then references either itself or an appropriate external module (such as
posix) in __dict__, it should always work.
With os.readlink, the issue
Hi Eric.
> First, to clarify our github repository situation...
gotcha
> Next, in continuing work on the unit tests for proc.py, we ran into another
> issue with the mocking code.
Nice catch, though for your example (os.readlink) won't this make the
tests platform dependent? Currently Beck (an
Hi Damian,
First, to clarify our github repository situation, both Megan and I will be
maintaining remote repos in github per Professor Danner's request so that
we each gain experience with version control systems. As we have been
working so far, I have been maintaining the mocking revisions in m
> The changes look great! I see no issues with merging to the master branch.
Great, pushed.
> Sorry about the reStructuredText inconvenience. I actually didn't even think
> of it -- I just meant to clean up the comments a bit, but I'll definitely be
> more careful in the future.
No worries. Ag
The changes look great! I see no issues with merging to the master branch.
Sorry about the reStructuredText inconvenience. I actually didn't even
think of it -- I just meant to clean up the comments a bit, but I'll
definitely be more careful in the future.
- Erik & Megan
On Thu, Jun 14, 2012 at 4
> 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
Ah ha, makes much more sense now - thanks. After some refle
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 re
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
