I didn't mean to replace the current (debug) assert but I wanted to add another one that would allow to be switch on or off on production builds.
The need for a new keyword (not syntax) comes from this difference.
I cannot think of another example that would convince you of the benefit of having a specific keyword for such a runtime assert. I do believe that having such a feature in non-debug build is more than interesting but indeed needed.
At some point, there should be a trade-off between to relying on a simple keyword/mechanism (for a runtime assert) versus the development cost of adding such a feature and maintaining it. Anyway, thanks for your feedback Serhiy, it helps.
________________________________
From: Python-ideas
By 'self-contained', I meant that using the assert keyword and its expression is sufficient. An inline assertive expression as the one you describe does not fulfill this assert requirement.
Sufficient for what? And why writing with using the existing syntax is not sufficient?
My proposal is simply to extend the current assert to non-debug builds and allow to switch it off/on at runtime.
The main property of the assert statement is that has a zero overhead in non-debug run. If you remove this property, it will be not the assert statement, and you will not need a special syntax support for writing this runtime check.
The syntax example I gave illustrated what I meant by syntax aware.
It doesn't illustrate why a new syntax is necessary. Or I can't understand this illustration. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/