> On May 1, 2020, at 14:34, Christopher Barker <python...@gmail.com> wrote: > > But it seems clear that "doing a big revamp if all the Exceptions and adding > alot more subclasses" is not supported. Which doesn't means that a few more > expansions wouldn't be excepted. > > So folks that like this idea may be best served by finding the lowest hanging > fruit, and suggesting jsut a few.
I think you’re right. It _might_ be accepted if someone did the work, but it’s probably a lot easier to get separate small changes with solid use cases in one by one. As long as you’re not being sneaky and pretending like you don’t have a master plan, and each of the changes is convincing, I think they’d have a much better chance. And there ought to be good use cases for “these builtin parse functions should have a .string with the input that failed so you don’t have to regex it out of the message” or “I need to distinguish this one kind of ValueError from all the other kinds” or whatever; a lot easier to argue for those use cases than something abstract and general. And almost any way it turns out seems like a win. Even if they all get rejected, better to know you were on the wrong track early rather than after a hundred hours of work. Or if it turns out to be more work than you expected and you get sick of doing it, at least you’ve improved some of the most important cases. Or maybe you’d just keep doing it and people just keep saying “fine”. Or maybe someone says, “Hold on, another one of these? They’re all good on their own, but shouldn’t we have some master plan behind it all?” and then you can point back to the master plan you posted in this thread that nobody wanted to read at the time, and now they’ll want to read it and start bikeshedding. :) (By “you” here I don’t mean you, Christopher; I mean Ram, or whoever else wants to do all this work.) By the way: > Python2 DID have a .message attribute -- I guess I should go look and find > documentation for the reasoning behind that, but it does seem like a step > backwards to me. In 2.6 and 2.7, it’s undocumented, and should always be either the same thing __str__ returns or the empty string. So, not particularly useful. I believe it exists as a consequence of the first time someone suggested “let’s clean up all the exceptions” but then that cleanup didn’t get started. It was added in 2.5, along with a planned deprecation of args, and a new rule for __str__ (return self.message instead of formatting self.args), and a new idiom for how newly-written exception classes should super: don’t pass *args, pass a single formatted string; anything worth keeping around for users is worth storing in a nicely named attribute the way SyntaxError and IOError always have. And Py3000 was going to change all the existing exceptions to use that new idiom. But that never happened, and 2.6 and 3.0 basically went back to 2.4: there’s no mention of message at all, args isn’t going to be deprecated, the rule for __str__ is the old one, etc. There are more custom attributes on more exceptions than there used to be, but they seem to mostly have grown on a case by case basis (and mostly on brand new exceptions) rather than in one fell swoop. Which implies that you were right about the best way to get anything done. _______________________________________________ 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/ODSM2MPGCQPPOMB4V5Q2BQFROLTP6KR3/ Code of Conduct: http://python.org/psf/codeofconduct/
