[EMAIL PROTECTED] wrote: > Thank you for the posting Andrae, it has increased my > knowledge. No problem, happy to help. > But my original point was there are cases (often involving > file iterators) where the problem's complexity seems to be > on the same order as problems involving iterate-to-shortest > solutions, but, while the latter have simple, one function > call solutions, solutions for the former are far more complex > (as your post illustrates). This seems at best unbalanced. > When encountered by someone with less than your level of > expertise, it leads to the feeling, "jeez, why is this simple > problem take hours to figure out and a half dozen function > calls?!?"
I agree, having had to think about how to implement padding with truncating api to implement your use-case, padding is a useful feature to have available. I didn't mean to imply otherwise. You asked why truncating is a common choice in the design of izip-like functions (Python, ML, Haskell, Scheme); my post was an attempt to answer that. The summary of my post is: 1. Either can be implemented in terms of the other. 2. Using a truncating zip instead of a padding zip leads to an incorrect result. 3. Using a padding zip instead of a truncating zip leads to non-termination. 4. A terminating bug is preferred to a non-terminating bug. Hence zip is generally truncating. Andrae Muys -- http://mail.python.org/mailman/listinfo/python-list
