On Thu, Jan 16, 2014 at 5:44 AM, spir wrote:
> This, in addition to the requirement of uniqueness which as you say is
> probably best met using a set (after filter). This may lead to you chosing
> to store, even if otherwise not truely necessary. An question is: what kind
> of data are combination
On Wed, Jan 15, 2014 at 6:12 AM, Steven D'Aprano wrote:
> You're selling youself short. From what I've seen of you on this list,
> you might be a beginner, but you've got the right sort of inquiring mind
> to go far as a programmer.
Thanks Steven, I've abruptly gotten clear how much work I have a
On Thu, Jan 16, 2014 at 5:32 AM, James Chapman wrote:
>
> In my unittest I don't want to run the ping command, (It might not be
> available on the build system) I merely want to check that a call to
> subprocess.Popen is made and that the parameters are what I expect?
You can mock `Popen` where i
Hi all
I have a question regarding mocking in unit testing.
Let's assume I have the following class:
---
import subprocess
class Pinger(object):
def ping_host(self, host_to_ping):
cmd_string = 'ping %s' % (host_to_ping)
cmd_args = cmd
On 01/12/2014 10:04 AM, Keith Winston wrote:
I've got this line:
for k in range(len(tcombo)):
tcombo_ep.append(list(combinations(tcombo, k+1)))
generating every possible length combination of tcombo. I then test
them, and throw most of them away. I need to do this differently, it
gets way
On 01/12/2014 07:40 PM, Keith Winston wrote:
Thanks Dave, that looks like a good idea, I've played a little with
one-line generators (? the things similar to list comprehensions), but
I'm still wrapping my head around how to use them.
You probably mean a generator *expression*. it's written lik
