On Tue, May 5, 2020 at 5:11 AM Alex Hall <alex.mojaki@gmail.com> wrote:
>
> On Mon, May 4, 2020 at 1:59 AM Steven D'Aprano <steve@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
I imagine there are few people who are too lazy to copy code from SO right now, and would be too lazy to import from itertools when the feature becomes available, but if it's a builtin then they're willing to make changes to some old code to make it a bit safer, even though that would break backward compatibility in their library. That's a weird combination.
And if that happens, the user still gets a clear exception which tells them what to do. That's not a bad experience when making an upgrade. There's likely to be other breaking changes too, the library just dropped support for Python 3.9.