On Aug 9, 2019, at 12:00, Ryan Fox <r...@rcfox.ca> wrote: > > > If you’re wondering why this works, it’s because Error and InputError don’t > > override __new__. Which should make it obvious why a tutorial aimed at > > novices doesn’t get into the details, but that’s why Python has reference > > manuals instead of just a tutorial.
> Okay, so this __new__/__init__ divide is sort of a hack because you can't > trust users to call super().__init__(...) on their user-defined exceptions? No, It’s not a hack; almost every immutable class that allows mutable subclasses in Python has a __new__ that the mutable subclasses rarely override, and a do-nothing __init__ that the mutable subclasses do. This does also save one remove one possibility for novices to make mistakes, and it also removes a line of boilerplate for most subclasses, but I don’t think either of those is the point; they’re just bonus. Anyway, you just define a new exception class the way the tutorial shows, and you get a round-trippable repr and proper tracebacks and args like magic; that’s all a novice needs to know—but it’s something we have to not break for them. > It sounds like BaseException.args is mostly used for generating strings? > Couldn't I just get away with overriding __str__, __repr__? Yes, but that means every class that doesn’t do the usual thing has to instead implement two or three extra methods, which is hardly reducing boilerplate, which was the goal. > I understand that existing built-in exception classes have some semantic > value associated with arguments in given positions, but that wouldn't apply > to new user-defined exceptions. And going forward, if you wanted to make your > tool extract a value, it doesn't seem like it should make a big difference to > access exc.arg[3] or exc.thing. As I said, if we were designing a new language from scratch, we’d almost surely want exceptions to be more like dataclasses or namedtuples than things that store the positional args in a tuple. But we’re obviously not going to change all of the builtin exceptions, the hundreds of other exceptions in the stdlib and popular libraries, and the thousands in specific projects people are working on overnight. Adding named attributes, and structure in general, to exceptions is a great goal, but it’s a very long-term goal (that’s been going on since 3.0); a new feature that requires us to already be most of the way there before it’s useful isn’t as useful as it appears. Something that preserves the existing magic for args and repr and half of str, while adding the other half of str (and maybe named attributes too?), that would be a step forward. But adding the their half of str while breaking the existing magic (and making named attributes harder rather than easier) doesn’t seem like it is. _______________________________________________ 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/6JW7FR3N65BHXEUUAMEODHWBRW3DHW4R/ Code of Conduct: http://python.org/psf/codeofconduct/
