[Python-ideas] Repurpose `assert' into a general-purpose check

[Elazar]

Just a note : in typechecked code (such as mypy's source code) assert is
used to guide the checker:

assert isinstance(x, CallableType)
return x.args  # checker knows it's valid

So the assert becomes a kind of type annotation. The runtime check helps
during tests, but is not that important - failure will be caught relatively
soon. And I believe that the ability to remove the check at runtime is
important, since isinstance calls have non-negligible impact on performance
in mypy.
(but other contributors here can correct me on this).

Elazar

בתאריך יום ג׳, 28 בנוב׳ 2017, 09:12, מאת Ivan Pozdeev via Python-ideas ‏<
python-ideas at python.org>:

> On 28.11.2017 8:59, Steven D'Aprano wrote:
> > On Tue, Nov 28, 2017 at 07:35:45AM +0300, Ivan Pozdeev via Python-ideas
> wrote:
> >
> >> Actually, the way I'm using them,
> >>
> >>      assert condition, "error message", type
> >>
> >> would probably be the most expressive way.
> > I disagree that is expressive -- I call it *misleading*. I see something
> > which looks like an assertion (that is, a checked comment, a contract, a
> > check on an internal piece of logic etc) but it is actually being used
> > as a test.
> >
> >
> >> I can do anything in any Turing-complete language without any changes to
> >> the language. That's no reason to never change anything, is it.
> > "We can change this" is not a reason to change this. There needs to be a
> > *good* reason to change, and you have given no good reasons for this
> > change.
> >
> >
> >> The rationale basically is:
> >> * As it was intended, the statement has no practical use -- basically a
> >> rudiment, due to disappear eventually
> > Nonsense. I make extensive use of assert as a way of checking
> > assertions, and I will fight tooth and nail against any proposal to
> > either remove it or to misuse it for public input tests instead of
> > assertions.
> I invite you to show me a single use case for those "assertions" because
> after ~20 years of experience in coding (that included fairly large
> projects), I've yet to see one.
>
> Any, every check that you make at debug time either
> * belongs in production as well (all the more because it's harder to
> diagnose there), or
> * belongs in a test -- something coded independently from the program
> (if your code as a whole cannot be trusted, how any specific part of it
> can?), or
> * isn't needed at all because a fault will inevitably surface somewhere
> down the line (as some exception or an incorrect result that a test will
> catch).
>
> Finally, I've got much experience using existing code outside its
> original use cases, where the original author's assumptions may no
> longer hold but the specific logic can be gauded to produce the desired
> result. Coding these assumptions in would undermine that goal.
>
> So, I see "debug assertions" as either intentionally compromizing
> correctness for performance (a direct opposite of Python's design
> principles), or as an inferiour, faulty, half-measure rudiment from
> times when CI wasn't a thing (thus not something that should be taught
> and promoted as a best practice any longer).
> >
> >> * It can instead be reused as syntax sugar to cover a very common use
> case
> > There is no need for such syntactic sugar. It would be harmful
> > to use assert for something which is not an assertion.
> >
> >
> >
>
> --
> Regards,
> Ivan
>
> _______________________________________________
> 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/20171128/ad861848/attachment.html>