On Fri, 15 May 2020 at 07:10, Brandt Bucher <brandtbucher@gmail.com> wrote:
This whole sub-thread of discussion has left me very confused. Was anything unclear in the PEP's phrasing here? If so, I'd like to improve it. The original quote is: "The goal here is not just to provide a way to catch bugs, but to also make it easy (even tempting) for a user to enable the check whenever using `zip` at a call site with this property."
It's not unclear, I'm just not sure I agree with the goal, and I'm not sure the proposal achieves that goal: I note that the PEP makes no mention in the rationale of the goal to make it "tempting" to use the flag. It's *only* mentioned as a reason to reject the itertools option. If you want to use that argument, you should explicitly state (and justify) the goal of making use of the flag "tempting" in the rationale for the feature. If it's not part of the rationale, your argument against an itertools function is weak (arguably flawed). My problems with the argument for rejection are: 1. Why do we want to "tempt" people to error when handling mismatched lengths? Certainly letting people catch errors easily is worthwhile, but rejecting arguments of different lengths may well *not* be an error ("be lenient in what you accept" is a well-known principle, even if not something that everyone agrees on in all cases). 2. I find "mode switch" arguments ugly, and I could even argue difficult to maintain (I can't easily use grep to check whether I missed any cases that I wanted to make strict). So I'm not tempted to use one - rather the opposite, it puts me off. (Note that I'm *not* arguing "mode switches are wrong", but rather that a mode switch makes the functionality "more tempting"). 3. I'm not even that sure it's easy to discover - a key factor in making it something people will use when needed. People who know of zip and zip_longest would naturally look for a zip_strict, not for a mode argument. (Yes, this is not a strong point - *nobody* can really tell what people in general will find "easy" - but it does at least reflect *my* thought processes). I do agree that a builtin is more "tempting" to use than a stdlib function (it's not logical, but I can see that people think that way - I do myself). What I don't agree with is that "tempting" is a goal that we want, or that being a builtin is sufficiently important to justify the downsides of a mode flag. We may just have to agree to differ, and leave the final decision to the SC. But let's at least be clear about the goals up front in the rationale section. Paul PS Despite my reservations, this is a well-reasoned and well presented PEP - you've put a lot of work into it, and it shows. Thanks!