> The conceptual idea here is that the "truncate" flag name would technically
> be a shorter mnemonic for "truncate_silently", so clearing it gives you an
> exception rather enabling padding behaviour.
>
> Flipping the sense of the flag also means that "truncate=True" will appear
> in IDE tooltips as part of the function signature, providing significantly
> more information than "strict=False" would.
"Significantly" more? I don't think so.
Truncate at what?
- some maximum length;
- some specific element;
- at the shortest input.
Given that the only input parameters are the iterables themselves, it's a stretch to even consider the first two as possibilities.
At some point people have to read the docs, not just the tooltips. If
you didn't know what zip does, seeing truncate=True won't mean anything
to you. If you do know what zip does, then the parameter names are
mnemonics, and strict=False and truncate=True provide an equal hint for
the default behaviour:
* if it's not strict, it is tolerant, stopping at the shortest;
* if it truncates, it truncates at the shortest input.
"strict=False" doesn't tell you whether the tolerant behaviour is truncation or padding. "truncate=True" does.
For the default case, strict=False and truncate=True are pretty much
equal in information.
Nope. If you don't already know that zip truncates the output by default, "truncate=True" gives you that information, while "strict=False" doesn't.
But for the case of non-default behaviour, strict=True is a clear
winner. It can pretty much only mean one thing: raise an exception.
But raise an exception when? In the context of this discussion, we know we mean "strict length checking, raising an exception for inconsistent lengths".
But "strict" on its own doesn't convey that - we could be requesting strict runtime type checking, for example, where each iterable is expected to keep producing items of the same type as was produced for the first tuple. Or we could be requesting a check that the values in the tuple aren't "None".
> That improved self-documentation then becomes what I would consider the
> strongest argument in favour of the flag-based approach:
I don't think that "truncate=False" (which can mean three different
things) is more self-documenting than `zip(*items, mode='strict')` or
`zip_strict()` (either of which can only mean one thing).
As noted above, "strict" just means "check more constraints" - it's at least as ambiguous as "don't truncate the output".
I do agree that the ambiguity of "truncate=False" is the biggest downside of that spelling, but learning that it means "raise an exception on a length mismatch instead of truncating the output iterator" isn't going to be any harder than learning what strict mode means.
Cheers,
Nick.