On Sun, Apr 26, 2020 at 10:52 AM David Mertz <mertz@gnosis.cx> wrote:
Let me try to explain why I believe that people who think they want zip_strict() actually want zip_longest().
Thanks for laying it out so clearly. However, reading your post makes it clear to me that I DO still want zip_strict() :-) It comes down to this:
If I have two or more "sequences" there are basically two cases of that.
so you need to write different code, depending on which case? that seems not very "there's only one way to do it" to me. Or alternately, we have a new function/mode that instead formulates this as:
try: for pair in zip_strict(stuff1, stuff2): process(pair) except ZipLengthError: raise UnequalLengthError("uh oh")
The hypothetical new style is fine. To me it looks slightly less good, but the difference is minimal.
To me it looks better than both of the other options -- and much better (particularly for beginners) than the _sentinal approach. If folks think that it really won't be used often, fine -- but I'm that you think that writing the extra has to be thought out checking code is actually just as good, or better, API. In fact, if I found myself writing either of those more than once, I'd write a utility function that did it (Probably with the second version, as it is reasonable in all cases). And it I, or others, are writting little utility functions for comon uses, maybe it DOES make sense to put in in the std library. It almost feels like the proponents of the new mode/function are hoping to avoid the processing that might need to be "rolled back" in some manner if there is a synchronization problem. Not me for one, I think it's a good idea because it would prevent all of us from writing those little utilities, and particularly for newbies, would provide an easy and obvious way to do it. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython