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@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@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
