Andrae Muys wrote: > [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.
(I assume "erroneously" should be inserted in front of "Using") OK. > 4. A terminating bug is preferred to a non-terminating bug. This is not self-evident to me. Is this somehow related to the design philosophy of functional languages? I was never aware of such a preference in conventional procedural languages (though I could easily be wrong). It also seems directly counter to Python's "no errors should pass silently" dogma -- a non termination seems more noticable than silent erroneous results. > Hence zip is generally truncating. I see your point in a theoretical sense, but it still seems to me be a pretty weak reason for making a practical decision about what should be in Python, particularly when the justification is being transfered from a functional programming domain to an object/procedural one. Is any language feature that might result in non-termination if erroneously used, to be banned? That doesn't seem very reasonble. (I realize you were explaining the rationale behind the FP choice, not necessarily taking a position on what should be in Python so the above comment is directed to the discussion at large.) -- http://mail.python.org/mailman/listinfo/python-list
