[Python-ideas] Specify an alternative exception for "assert"

[Ryan Gonzalez]

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 at gmail.com> wrote:

>
>
> On Mon, May 2, 2016 at 5:17 PM, Random832 <random832 at 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 at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160502/23bec3af/attachment-0001.html>