I feel like you just brought up the exact issue. Assertions should *never* be used for things like this. Because, one day, some stupid idiot is going to use assertions to perform some sort of data validation, someone else will use that library with -O, and the world will explode. It's just far too attractive to use but far too easy to misuse. And, if you really want: if my_cond: raise MyError('abc') Compare that to: assert my_cond, MyError('abc') Also, RPython uses assertions for error handling. Trust me, dealing with that is *not* fun. -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On May 2, 2016 10:29 AM, "Giampaolo Rodola'" <g.rodola@gmail.com> wrote:
On Mon, May 2, 2016 at 5:17 PM, Random832 <random832@fastmail.com> wrote:
On Mon, May 2, 2016, at 11:14, Guido van Rossum wrote:
On Mon, May 2, 2016 at 8:01 AM, Ryan Gonzalez <rymg19@gmail.com> wrote:
Other than the fact that this would completely fail when run with -O...
But maybe that's fine, or intended.
I can see a fair number of uses for this, including subclasses of AssertionError.
I think this would be an attractive nuisance, and if it's implemented at all it should forbid types that are *not* subclasses of AssertionError in order to mitigate that.
Why such a constraint? I think most of the times the desired exception would be either ValueError or TypeError, both of which do not inherit from AssertionError.
-- Giampaolo - http://grodola.blogspot.com
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/