On Tue, Mar 20, 2012 at 10:43 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
But according to Nick's post, there's some sort of uniquification that is done, and the algorithm currently used computes the whole list anyway.
I suppose that one could do the uniquification lazily, or find some other way to avoid that computation. Is it worth it to optimize an unlikely case?
Yeah, the only where I thought retaining the list output made particular sense was "collapse_address_list". I have no problem with that operation expecting a real sequence as input and producing an actual list as output, since the entire (deduplicated) sequence will eventually end up in memory for checking purposes anyway, even if the result was an iterator rather than a list and it already has "list" in its name. The other instances I noticed should all just be a matter of replacing "output.append(value)" calls with "yield value" instead, so it seems sensible to standardise on a Py3k style iterators-instead-of-lists API for the standard library version of the module. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia