Brad wrote: > On Jul 3, 12:57 am, Steven D'Aprano <st...@remove-this- > cybersource.com.au> wrote: >> I've never needed such a split function, and I don't like the name, and >> the functionality isn't general enough. I'd prefer something which splits >> the input sequence into as many sublists as necessary, according to the >> output of the key function. > > That's not a bad idea, I'll have to experiment with the alternatives. > My thought process for this, however, was that filter itself already > splits the sequence and it would have been more useful had it not > thrown away "half" of what it discovers. It could have been written to > returned two sequences with very litter perf hit for all but very > large input sequences, and been useful in more situations. What I > *really* wanted was a way to make filter itself more useful, since it > seems a bit silly to have two very similar functions.
It's not that easy. filter is nearly by definition a lazy function. The various split/group functions is impossible to be made an efficient iterator, since they must traverse the whole list before being sure that they have finished the group/part of the split (or even to be sure that they have all the group keys). > Maybe this would be difficult to get into the core, but how about this > idea: Rename the current filter function to something like "split" or > "partition" (which I agree may be a better name) and modify it to > return the desired true and false sequences. Then recreate the > existing "filter" function with a wrapper that throws away the false > sequence. filter has a very deep root in functional programming, I doubt it will change any time soon. Also, consider infinite iterators. With the "filter as wrapper to partition" scheme, it is impossible for split/group/partition to use infinite iterator. -- http://mail.python.org/mailman/listinfo/python-list
