Christopher's quoting is kinda messed up and I can't be bothered fixing it, sorry, so you'll just have to guess who said what :-) On Tue, May 05, 2020 at 01:03:30PM -0700, Christopher Barker wrote:
"If its builtin people will be more likely to use it, so we need to make
it builtin."
This argument will apply to **literally** every function and class in the standard library.
But we are not talking adding a new builtin.
I didn't say a *new* builtin. You are talking about having this related but distinct functionality piggy-back on top of the existing tolerant zip function, distinguishing them by a flag. I trust you wouldn't try to argue that `int(string, base)` is not a builtin function? :-)
Firstly, we would have to agree that "maximizing the number of people using the strict version of zip" is our goal. I don't think it is.
Neither do I. But I am suggesting that "maximizing the number of people that need a strict version of zip will use it" Rather than, say, checking the length of the inputs before calling zip. Or writing their own version.
Okay, but a function in the std lib is sufficient for that. If you want to argue against the alternatives: - use more-itertools - make it a recipe in the docs then "more people will use it" is a good argument for putting it into the stdlib. But why should we fear that there will be people doing without, or rolling their own, because it's not builtin? `zip_longest` has been in the stdlib for at least a decade. We know it has use-cases, and unlike this strict version of zip the need for this was established and proven long ago. If there are people doing without, or rolling their own, zip_longest because they either don't know about, or cannot be bothered, importing from itertools, should it be in builtins too?
Why is zip_longest different? What if we want to add a fourth or fifth flavour of zip? Do we then have three flags on zip and have to deal with eight combinations of them?
no -- but we could (and I think should) have a ternary flag, so that zip_longest becomes unnecessary. And we'd never get to eight combinations: you can't have longest and shortest behavior at the same time!
A ternary flag of strict = True, False or what? This demonstrates why the "constant flag" is so often an antipattern. It doesn't scale past two behaviours. Or you end up with a series of flags: zip(*iterators, strict=False, longest=False, fillvalue=None) and then you have to check for incompatible combinations: if longest and strict: raise TypeError('cannot combine these two options') and it becomes worse the more flags you have. Or you end up with deprecated parameters: def zip(*iterators, strict=_sentinel, mode=ZIP_MODES.SHORTEST): if strict is not _sentinel: raise DeprecationWarning
But if we did, then would it be better to have eight separate functions in itertools?
You wouldn't have eight separate functions. You would have four. But to distinguish four independent modes in a single function, you need three flags, and that gives you 2**3 = 8 combinations to deal with, all of which have to be checked, and exceptions raised if the combination is invalid. -- Steven