[ python-Feature Requests-1726707 ] add itertools.ichain function and count.getvalue

SourceForge.net noreply at sourceforge.net
Mon May 28 07:32:52 CEST 2007


Feature Requests item #1726707, was opened at 2007-05-28 04:51
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726707&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: add itertools.ichain function and count.getvalue

Initial Comment:
def ichain(seq):
  for s in seq:
     for t in s: yield t

This is like itertools.chain except seq is lazy-evaluated element-by-element.  Obvious use cases:

# equivalent of perl's "while (<>) { ... } "
for line in ichain(all_lines_of(f) for f in list_of_filenames):
   do_something_with(line)

# generate infinite sequence 1,1,1,2,2,2...
seq = ichain(repeat(i,3) for i in count(1))

Also requested: it would be nice to be able to get the current counter value from a count() instance without incrementing it, e.g.
   c = count()
   ...
   i = c.getvalue()

This is clearly useful since repr(c) does something like that internally.


----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2007-05-28 05:32

Message:
Logged In: YES 
user_id=72053
Originator: YES

Well, I use ichain all the time in my own code, and the difference doesn't
seem hard to explain.  The chain(*map(open, list_of_filenames)) substitute
is no good because it opens all the files simultaneously, and there might
be millions of them, so you run out of file descriptors.  Not having ichain
in the module leads to users writing such inferior substitutes, which can
work for small examples and end up breaking or performing poorly with large
examples.  Also, using nested for-loops isn't so nice if you want to pass
the resulting generator to some other function (maybe islice or groupby or
something).  It means you've got to wrap the statements in a named
function, which I suppose is doable, but ends up with unnecessary Java-like
code bloat.

A read-only attribute is fine for count.getvalue.  I guess it could be
count.value instead of getvalue.  I'll submit a separate RFE as suggested.



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-28 05:15

Message:
Logged In: YES 
user_id=80475
Originator: NO

Am rejecting ichain() because it adds too little in the way of
functionality to be worth the confusion associated with having two like
named functions and two ways to handle most problems.

Also, I think that some the use cases for lazy-evaluated inputs are better
served by using explicit for-loops and not itertools (too much magic
underneath the hood).  I do see some value in having lazy-evaluated inputs
but do not think it is worth complexifying the module any further.

FWIW, the first example has no need for lazy evaluation.  I would write it
as:

   for line in chain(*map(open, list_of_filenames)):
        do_something_with(line)

Or, just use plain vanilla Python:

   for filename in list_of_filenames:
       for line in open(filename):
            do_something_with(line)

Please submit a separate feature request for count.getvalue().  I'm
thinking it should be a read-only attribute instead of a method.  The only
downside is that it complicates the explanation of an otherwise trivially
simple tool.  


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726707&group_id=5470


More information about the Python-bugs-list mailing list