On 05/14/2020 11:13 AM, Brandt Bucher wrote:
I claimed to have found "dozens of other call sites in Python's standard
library and tooling where it would be appropriate to enable this new
feature". You asked for references, and I provided two dozen cases of
zipping what must be equal length iterables.
I said they were "appropriate", not "needed" or even "recommended". These
are call sites where unequal-length iterables, if encountered, would be
an error that I would hope wouldn't pass silently.
Very good point.
Besides, I don't thinkit's beyond the realm of imagination for a future
refactoring of severalof the "Mismatch cannot happen." cases to introduce
a bug of this kind.
Which seems besides the point. As you say, if the lengths are mismatched
then a bug has appeared and if the check is nearly free there's no reason
not to do it.
Ethan Furman wrote:
Did you vet them ...
Of course. I spent hours vetting them, to the point of researching the GNU
tar extended sparse header and Apple property list formats (and trying to
figure out what the hell was happening in `os._fwalk`) just to make sure
my understanding was correct.
Glad I'm not the only one that didn't immediately get that os._fwalk code.
Ethan Furman wrote:
Not the call itself, but the running of zip.
I wouldn't call my implementation "clever", but it differs from both of
those options. We only need to check if we're strict when an error occurs
in one of our iterators, which is a situation the C code for `zip` already
needs to explicitly handle with a branch. So this condition is only hit on
the "last" `__next__` call, not on every single iteration.
Ah, so this is why the strict version may consume an extra element -- it has
to check if any remaining iterators have elements, while the non-strict version
can just quit as soon as any of the iterators are exhausted.
>>> one = iter([1, 2])
>>> six = iter([6, 7, 8])
>>> zip(one, six)
(stuff)
>>> next(six)
8
vs
>>> zip_strict(one, six)
(stuff)
>>> next(six)
(crickets)
I went ahead and ran some rough PGO/LTO benchmarks...
Can you do those with _pydecimal? If performance were an issue anywhere I would
expect to see it with number crunching.
---
Paul Moore and Chris Angelico have made good arguments in favor of an itertools
addition which haven't been answered yet.
Regardless, I think you've made the point that /a/ solution is very desirable.
So the real debate is whether it should be a flag, a mode, or a separate
function.
I am still
-1 on the flag.
--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/KMCGAJV7QKTTKFYDNJVZ3HSW5NC3BXQL/
Code of Conduct: http://python.org/psf/codeofconduct/
