On Sun, Apr 26, 2020 at 10:52 AM David Mertz <me...@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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/V4TKU4QMKQNRKUOI7ZZMNS4N6Q5QAFKA/
Code of Conduct: http://python.org/psf/codeofconduct/
