Here’s another advantage of having a separate function that I didn’t see acknowledged in the PEP: If strict behavior is a better default for a zip-like function than non-strict, then choosing a new function would let you realize that better default. In contrast, by adding a new argument to the existing function, the function you use will forever have the less preferred default. In terms of what is a better default, I would say strict is better because errors can’t pass silently: If errors occur, you can always change the flag. But you would be doing that explicitly. —Chris On Fri, May 15, 2020 at 6:57 AM Paul Ganssle <paul@ganssle.io> wrote:
I'm on the fence about using a separate function vs. a keyword argument (I think there is merit to both), but one thing to note about the separate function suggestion is that it makes it easier to write backwards compatible code that doesn't rely on version checking. With `itertools.zip_strict`, you can do some graceful degradation like so:
try: from itertools import zip_strict except ImportError: zip_strict = zip
Or provide fallback easily:
try: from itertools import zip_strict except ImportError: def zip_strict(*args): yield from zip(*args) for arg in args: if next(arg, None): raise ValueError("At least one input terminated early.")
There's an alternate pattern for the kwarg-only approach, which is to just try it and see:
try: zip(strict=True) HAS_ZIP_STRICT = True except TypeError: HAS_ZIP_STRICT = False
But I would say it's considerably less idiomatic.
Just food for thought here. In the long run this doesn't matter, because eventually 3.9 will fall out of everyone's support matrices and these workarounds will become obsolete anyway.
Best, Paul
On 5/15/20 5:20 AM, Stephen J. Turnbull wrote:
Brandt Bucher writes:
Still agreed. But I think they would be *better* served by the proposed keyword argument.
This whole sub-thread of discussion has left me very confused. Was anything unclear in the PEP's phrasing here?
I thought it was quite clear. Those of us who disagree simply disagree. We prefer to provide it as a separate function. Just move on, please; you're not going to convince us, and we're not going to convince you. Leave it to the PEP Delegate or Steering Council.
I wouldn't confuse "can" and "should" here.
You do exactly that in arguing for your preferred design, though.
We could implement the strictness test with an argument to the zip builtin function, but I don't think we should. I still can't think of a concrete use case for it from my own experience. Of course I believe concrete use cases exist, but that introspection makes me suspicious of the claim that this should be a builtin feature, with what is to my taste an ugly API.
Again, I don't expect to convince you, and you shouldn't expect to convince me, at least not without more concrete and persuasive use cases than I've seen so far.
Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6NQZIDVM... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/A4UGQRMK... Code of Conduct: http://python.org/psf/codeofconduct/