On Fri, 25 Sep 2020 at 22:05, Chris Angelico <ros...@gmail.com> wrote: > > On Sat, Sep 26, 2020 at 6:56 AM Oscar Benjamin > <oscar.j.benja...@gmail.com> wrote: > > > > There are many common bugs that arise as a result of exceptions that > > are overlooked. There are also often simple ways to rewrite the code > > so that it becomes exception free. For example in sympy: > > > > if x.is_positive: # never raises (excepting bugs) - False if > > indeterminate > > if x > 0: # raises if indeterminate > > The novice believes that his ultimate goal is to stop the program from > crashing. If "exception free" is your goal, then sure, this feature > will certainly help you. I don't want Python to have language support > for something that is primarily aimed at helping novices to remain > forever novices.
Yeah, because real professionals write applications that spew out tracebacks to their users for perfectly valid inputs and real users love that :) There are good reasons for writing your code in such a way that it handles all cases rather than blowing up. Of course if you can't handle all cases then that's one good reason for raising an exception. Raising an exception just because you wrote your code in slightly the wrong way is obviously something to avoid though. A tool that helps you to see non-obvious ways that exceptions can be raised can be very useful. > > That is *not* what I am suggesting. Rather only an explicit raises > > hint could give an error so the above is fine. The type checker knows > > that g might raise FooError but there's nothing wrong with raising an > > error without any declaration. However the type checker *would* > > complain about this: > > > > def f(): raises FooError > > ... > > > > def g(): raises None > > f() # <--- typecheck error because g claims that it does not raise > > > > Okay. So what exceptions can a "raises None" function raise? Or if it > "raises FooError", then what, other than FooError, can it raise? If > this is to have the blessing of the language, there needs to be an > absolutely 100% consistent answer to that question. And there's only > one valid answer that will always be correct, and it's the useless > one: BaseException. The way that I would propose is this: Yes, g can possibly raise any exception class. As you say it's not generally possible to verify that arbitrary Python code can not raise any exception outside of a nontrivial set (BaseException). However g can not raise any exception from a function that was explicitly annotated as raising that exception. If some function h is annotated as raising FooError then a FooError from h will not arise from calling g. Oscar _______________________________________________ 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/7O5ITX23PIFDM3L3CUKB657224GULXPA/ Code of Conduct: http://python.org/psf/codeofconduct/
