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 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/