This is a straw man in regards to backwards compatibility. This particular (sub)thread is about whether if this zip-is-strict either as a separate name or a Boolean flag or some other flag of zip should be a built-in or be in e.g. itertools.

It is not about breaking backwards compatibility (presumably by making it the default behaviour of zip).

On Tue, 5 May 2020, 17:17 Chris Angelico, <rosuav@gmail.com> wrote:
On Wed, May 6, 2020 at 1:44 AM Rhodri James <rhodri@kynesim.co.uk> wrote:
>
> On 05/05/2020 13:53, Henk-Jaap Wagenaar wrote:
> > Brandt's example with ast in the stdlib I think is a pretty good example of
> > this.
> >
> > On Tue, 5 May 2020 at 13:27, Rhodri James <rhodri@kynesim.co.uk> wrote:
> >
> >> On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote:
> >>> A function that is a "safer" version in some "edge case" (not extra
> >>> functionality but better error handling basically) but that does
> >> otherwise
> >>> work as expected is not something one will search for automatically. This
> >>> is zip versus zip-with-strict-true.
> >>
> >> I'm sorry, I don't buy it.  This isn't an edge case, it's all about
> >> whether you care about what your input is.  In that sense, it's exactly
> >> like the relationship between zip and zip_longest.
>
> Interesting, because I'd call it a counterexample to your point.  The
> bug's authors should have cared about their input, but didn't.
>

Should they? I'm not sure how well-supported this actually is. If you
hand-craft an AST and then compile it, is it supposed to catch every
possible malformation? Has Python ever made any promises about
*anything* regarding manual creation of AST nodes? Maybe it would be
*nice* if it noticed the bug for you, but if you're messing around
with this sort of thing, it's not that unreasonable to expect you to
get your inputs right.

If you're creating a language from scratch and want to have separate
"strict" and "truncating" forms of zip, then by all means, go ahead.
But I think the advantage here is marginal and the backward
compatibility break large.

ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3JKQREPI4CE2ZEB75URDQMGKEWHJEJVO/
Code of Conduct: http://python.org/psf/codeofconduct/