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/