On Wed, Apr 22, 2020 at 01:26:02PM -0700, Andrew Barnert wrote:
On Apr 21, 2020, at 16:02, Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Apr 21, 2020 at 12:25:06PM -0700, Andrew Barnert via Python-ideas wrote:
On Apr 21, 2020, at 01:36, Serhiy Storchaka <storchaka@gmail.com> wrote: except ValueError: # assuming that’s the exception you want? For what it’s worth, more_itertools.zip_equal raises an UnequalIterablesError, which is a subclass of ValueError.
I’m not sure whether having a special error class is worth it, but that’s because nobody’s providing any examples of code where they’d want to handle this error. Presumably there are cases where something else in the expression could raise a ValueError for a different reason, and being able to catch this one instead of that one would be worthwhile. But how often? No idea.
At a guess, I’d say that if this has to be a builtin (whether flag-switchable behavior in zip or a new builtin function) it’s probably not worth adding a new builtin exception, but if it’s going to go into itertools it probably is worth it.
Why?
Well, you quoted the answer above, but I’ll repeat it: [...]
I saw that, so let me rephrase my question: why it is worth a subclass if this is in itertools but not if it's a builtin? Sorry for being so terse in my question. You haven't really given an answer to that, as such, but I think that it is no longer relevant given the below.
For a little more detail: [...] The question in every case is: do you often need to distinguish this case?
Indeed.
As I said, I don’t know the answer to that question, because none of the people saying they need an exception here have given any examples where they’d want to handle the exception, and it’s hard to guess how people want to handle an exception when you don’t even know where and when they want to handle it. So I took a guess to start the discussion.
And that's the missing piece I was looking for, thank you. You weren't so much advocating for this as just exploring the options. Fair enough. -- Steven