On 16/05/2020 17:14, Guido van Rossum wrote:
On Sat, May 16, 2020 at 1:26 AM Steven D'Aprano <steve@pearwood.info> wrote:

> * zip(strict=True)       +1
> * zip(mode='strict')     -0
> * itertools.zip_strict() -0.5
> * zip.strict()           -1  (but really, I'd like to make this -1e10)

I spent a significant amount of time and mental energy explaining in
detail why a boolean flag is a poor API and is objectively the wrong
interface here. This is not just a matter of personal taste: there are
reasons why a flag is wrong here.
[snip]

- your preferred option is the least open to future enhancements;

Given zip's stability, I doubt there will be a lot of other future enhancements any time soon. In Python's culture, boolean flag is the most common way to modify the behavior of a function. The reasons have to do with tradition (lots of existing APIs use this pattern) as well as ease of implementation (*also* in the Zen!), and also with how people *think* about certain APIs. Zip-strict is "like zip, but strict(er) in its requirements".
 
But Steven has a point.  zip(mode='strict') would allow zip_longest behaviour to be incorporated into zip at some future time, should that be considered desirable.
(And conceivably other behaviours that might crop up.  I don't have any use cases, but one possibility might be "stop zipping after N items".)
Whereas doing that with a boolean `strict` would lead, as others have pointed out, to an ugly API (2 booleans that can't both be True).
Rob Cliffe