On Fri, 15 May 2020 at 07:10, Brandt Bucher <brandtbuc...@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!
_______________________________________________
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/IVLRMEXU454ZHT2SZJY374VSOZJHIGKE/
Code of Conduct: http://python.org/psf/codeofconduct/
