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.

--

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/