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