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, <ros...@gmail.com> wrote: > On Wed, May 6, 2020 at 1:44 AM Rhodri James <rho...@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 <rho...@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-le...@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/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/CZX6FMFGUAPXZYKJL3C6L2P3YOSGBAAA/ Code of Conduct: http://python.org/psf/codeofconduct/
