> On Apr 21, 2020, at 16:02, Steven D'Aprano <st...@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 <storch...@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: >> 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. For a little more detail: A few people (like Soni) keep trying to come up with general-purpose ways to differentiate exceptions better. The strong consensus is always that we don’t need any such thing, because in most cases, Python gives you just enough to differentiate what you actually need in most code. (That wasn’t quite true in Python 2, but it is now.) We have LookupError with subclasses KeyError and IndexError, but not additional subclasses IndexTooBigError and IndexTooSmallError, and so on. For the IOError subclasses, Python does kind of lean on C/POSIX, but that’s still good enough that it’s fine. The question in every case is: do you often need to distinguish this case? In this case: will the zip_strict postcondition violation be used in a lot of places where there are other likely sources of ValueError that need to be distinguished? If so, it should be a separate subclass. If that will be rare, it shouldn’t. 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. If you have a different guess, fine. But really, we need the people who have code in mind that would actually use this to show us that code or tell us about it. > I know that the Python community has a love-affair with more-itertools, > but I don't think that it is a well-designed library offering good APIs. > It's a grab-bag of "everything including the kitchen sink". Just because > they use a distinct exception doesn't mean we should follow them. If I thought we should just do what more-itertools does without thinking, I would have said “more-itertools has a separate exception, so we should”, rather than saying “For what it’s worth, more-itertools has a separate exception” and then concluding that I don’t know if we actually need one and we need to look at actual examples to decide. When all else is equal, I think it’s worth being consistent with more-itertools just because that way we get an automatic backport. But that’s not a huge win, and quite often, all else isn’t equal, so looking at what more-itertools does and why isn’t the answer, it’s just one piece of information to throw into the discussion. And I think that’s the case here: their design raises a question for us to answer, but it doesn’t answer it for us. _______________________________________________ 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/M2IYSPBE37G55QQ4PL2RDFJ3BXLBTI56/ Code of Conduct: http://python.org/psf/codeofconduct/
