On 13May2020 16:20, chris.the.develope...@gmail.com
<chris.the.develope...@gmail.com> wrote:
I'm working with developers that have decided to use asserts every time they
want to throw an exception.
Since asserts are disabled when the optimiser is activated, I'd say
these devs don't speak Python.
Also, AssertionErrors are a pretty vague way to raise an exception, and
there's a whole suite of exceptions available.
I feel that their should be something that dissuades this behavior in
the language design.
Bad code can be written in any language, of any design.
You would FAR better off finding out _why_ they want to use this
approach, since the language documentation makes it clear that asserts
may have NO EFFECT AT RUNTIME, depending on the mode.
The only thing I can think of for this is that:
assert x > 0
is much more concise than:
if x <= 0:
raise ValueError("x should be > 0, got %s" % x)
This could be making asserts not recoverable, making it so you can't
stop assert failures from printing to stdout, forcing the return code
to -1 on process termination if an assert fails, or something else.
Making asserts inflexible, in a complete lack of consistency with every
other exception type, seems very artificial. You'lll just push the devs
from misusing asserts to misusing something else.
_Are_ your devs catching AssertionError and preventing programme
termination?
Cheers,
Cameron Simpson <c...@cskk.id.au>
_______________________________________________
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/KF5VUQ247BPM62FTI6FRKPTERJTITSIM/
Code of Conduct: http://python.org/psf/codeofconduct/
