icmp - should this go in itertools?

[Tom Anderson]

Hi all,

This is a little function to compare two iterators:

def icmp(a, b):
for xa in a:
try:
xb = b.next()
d = cmp(xa, xb)
if (d != 0):
return d
except StopIteration:
return 1
try:
b.next()
return -1
except StopIteration:
return 0

It's modelled after the way cmp treats lists - if a and b are lists,
icmp(iter(a), iter(b)) should always be the same as cmp(a, b).

Is this any good? Would it be any use? Should this be added to itertools?

tom

--
I content myself with the Speculative part [...], I care not for the
Practick. I seldom bring any thing to use, 'tis not my way. Knowledge
is my ultimate end. -- Sir Nicholas Gimcrack

[Roy Smith]

Tom Anderson <tw**@urchin.earth.li> wrote:

It's modelled after the way cmp treats lists - if a and b are lists,
icmp(iter(a), iter(b)) should always be the same as cmp(a, b).

Is this any good? Would it be any use? Should this be added to itertools?

Whatever happens, please name it something other than icmp. When I read
"icmp", I think "Internet Control Message Protocol".

[Diez B. Roggisch]

Tom Anderson wrote:

Hi all,

This is a little function to compare two iterators:

def icmp(a, b):
for xa in a:
try:
xb = b.next()
d = cmp(xa, xb)
if (d != 0):
return d
except StopIteration:
return 1
try:
b.next()
return -1
except StopIteration:
return 0

It's modelled after the way cmp treats lists - if a and b are lists,
icmp(iter(a), iter(b)) should always be the same as cmp(a, b).

Is this any good? Would it be any use? Should this be added to itertools?

Whilst not a total itertools-expert myself, I have one little objection
with this: the comparison won't let me know how many items have been
consumed. And I end up with two streams that lack some common prefix
plus one field. I'm just not sure if there is any usecase for that.

However, _if_ there is one, I'm all for adding it to itertools - it
seems to be in the appropriate spirit.

Regards,

Diez

[Jorgen Grahn]

On Fri, 25 Nov 2005 21:58:00 -0500, Roy Smith <ro*@panix.com> wrote:

Tom Anderson <tw**@urchin.earth.li> wrote:

It's modelled after the way cmp treats lists - if a and b are lists,
icmp(iter(a), iter(b)) should always be the same as cmp(a, b).

Is this any good? Would it be any use? Should this be added to itertools?

Whatever happens, please name it something other than icmp. When I read
"icmp", I think "Internet Control Message Protocol".

Me too, but I see that as an added bonus ;-). OTOH, if this is part of
itertools or some other module, "itertools.cmp" would be a more logical
name. (On the third hand, as someone else said, I don't see the use case for
this.)

/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!

[Tom Anderson]

On Fri, 25 Nov 2005, Roy Smith wrote:

Tom Anderson <tw**@urchin.earth.li> wrote:

It's modelled after the way cmp treats lists - if a and b are lists,
icmp(iter(a), iter(b)) should always be the same as cmp(a, b).

Is this any good? Would it be any use? Should this be added to itertools?

Whatever happens, please name it something other than icmp. When I read
"icmp", I think "Internet Control Message Protocol".

Heh! That's a good point. The trouble is, icmp is clearly the Right Thing
to call it from the point of view of itertools, continuing the pattern of
imap, ifilter, izip etc. Wouldn't it be clear from context that this was
nothing to do with ICMP?

tom

--
Gotta treat 'em mean to make 'em scream.

[Tom Anderson]

On Sat, 26 Nov 2005, Diez B. Roggisch wrote:

Tom Anderson wrote:

Is this any good? Would it be any use? Should this be added to itertools?
Whilst not a total itertools-expert myself, I have one little objection
with this: the comparison won't let me know how many items have been
consumed. And I end up with two streams that lack some common prefix
plus one field.

Good point. It would probably only be useful if you didn't need to do
anything with the iterators afterwards.

One option - which is somewhat icky - would be to encode that in the
return value; if n is the number of items read from both iterators, then
if the first argument is smaller, the return value is -n, and if the
second is smaller, it's n. The trouble is that you couldn't be sure
exactly how many items had been read from the larger iterator - it could
be n, if the values in the iterators differ, or n+1, if the values were
the same but the larger one was longer.
I'm just not sure if there is any usecase for that.

I used it in my ordered dictionary implementation; it was a way of
comparing two 'virtual' lists that are lazily generated on demand.

I'll go away and think about this more.

tom

--
Gotta treat 'em mean to make 'em scream.