On Sat, May 02, 2020 at 09:54:46AM +0200, Alex Hall wrote:
I would say that in pretty much all cases you wouldn't catch the exception. It's the producer's responsibility to produce correct inputs, and if they don't, tell them that they failed in their responsibility.
The underlying core principle is that programs should fail loudly when users make mistakes to help them find those mistakes.
Maybe. It depends on whether it is a meaningful mistake, and the cost of the loud failure versus the usefulness of silent truncation. py> x = 123456789.0000000001 py> x == 123456789 True Should that float literal raise or just truncate the value? How about arithmetic? py> 1e50 + 1 == 1e50 True I guess once in a while it would be useful to know that arithmetic was throwing away data, and the IEEE floating point standard allows that as an optional trap, but can you imagine how obnoxious it would be to have it happen all the time? Sometimes silently throwing away data is the right thing to do. "Errors should never pass silently" depends on what we mean by "error". Is it an error to call str.upper() on a string that contains no letters? Perhaps upper() should raise an exception if it doesn't actually convert anything, rather than silently doing nothing. If I'm expecting a string of alphabetical letters, but get digits instead, it might be useful for upper() to raise. name.upper(strict=True) Would I write my own upper() to do this? No. Should it become a builtin? Probably not. So bringing it back to zip... I don't think I ever denied that, in principle at least, somebody might need to raise on mismatched lengths. (If I did give that impression, I apologise.) I did say I never needed it myself, and my own zip_strict function in my personal toolbox remains unused after many years. But somebody needs it? Sure, I'll accept that. But I question whether *enough* people need it *often enough* to make it a builtin, or to put a flag on plain zip. Rolling your own on top of zip_longest is easy. It's half a dozen lines. It could be a recipe in itertools, or a function. It has taken years for it to be added to more-itertools, suggesting that the real world need for this is small. "Not every two line function needs to be a builtin" -- this is six lines, not two, which is in the proposal's favour, but the principle still applies. Before this becomes a builtin, there are a number of hurdles to pass: - Is there a need for it? Granted. - Is it complicated to get right? No. - Is performance critical enough that it has to be written in C? Probably not. - Is there agreement on the functionality? Somewhat. - Could that need be met by your own personal toolbox? - or a recipe in itertools? - or by a third-party library? - or a function in itertools? We've heard from people who say that they would like a strict version of zip which raises on unequal inputs. How many of them like this enough to add a six line function to their code? My personal opinion is that given that Brandt has found one concrete use for this in the stdlib, it is probably justifiable to add it to itertools. Whether it even needs a C accelerated version, or just a pure Python version, I don't care, but then I'm not doing the work :-)
The most common use for this I have seen in the discussion is:
"I have generated two inputs which I expect are equal, and I'd like to be notified if they aren't"
If there's a different use case I'm not aware of it, can someone share?
Sorry for the confusion, I intended to distinguish between the two cases: 1. I have generated two inputs which I expect are equal, and I want to assert that they are equal when I process them. 2. I consume data generated by someone else, and it is *their* responsibility to ensure that they are equal in length. Sorry that this was not clear. In the second case it is (in my opinion) perfectly acceptable to put the responsibility on the producer of the data, and silently truncate any excess data, rather than raise. Just as converting strings to floats silently truncates any extra digits. Let the producer check the lengths, if they must. [...]
The problem is not that they have to look there, it's that they have to *think to look there*. itertools might not occur to them. They might not even know it exists.
Yes? Is it our responsibility to put everything in builtins because people might not think to look in math, or functools, or os, or sys?
Note that adding a flag is essentially adding to the (empty) namespace that is zip's named arguments. Adding a new function is adding to a much larger namespace, probably itertools.
I don't agree with that description. A function signature is not a namespace. -- Steven