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/3JKQRE... Code of Conduct: http://python.org/psf/codeofconduct/