On Tue, May 5, 2020 at 5:11 AM Alex Hall <alex.moj...@gmail.com> wrote: > > On Mon, May 4, 2020 at 1:59 AM Steven D'Aprano <st...@pearwood.info> wrote: >> Can we agree to meet half-way? >> >> - there are legitimate, genuine uses for zip_strict; >> >> - but encouraging people to change zip to zip_strict "just in case" >> in the absence of a genuine reason is a bad thing. > > No, I stand by my position for now that "just in case" is a genuine reason > and that safety outweighs convenience and efficiency. I haven't been given a > reason to believe that your concerns would be significant. >
If we were at the very beginning of the zip() function's life, and could guide its future without any baggage from the past, then "just in case" might be a valid justification. But that's not where we are. Is "just in case" worth the likely break of backward compatibility? I say "likely" because, technically, the Python language and standard library would be backward compatible; but in order to get any benefit from this change, there would need to be places where the strict mode is used, and that's going to mean people change code to be more strict, "just to be safe". Is THAT worth it? 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/ENS7U6A2RDCYUDC3T5FW2GFC5PGZWXPC/ Code of Conduct: http://python.org/psf/codeofconduct/
