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
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/6NQZIDVMGPXA5QJWTKWJFZUUUAYQAOH4/
> 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/A4UGQRMKUZDBHEE4AFJ4PL6AUUTAPF7N/
Code of Conduct: http://python.org/psf/codeofconduct/