I've used Python for 20 years, and programming in general for about 40 now. I think almost EVERY large code base I've seen used asserts in their intended way. I frequently use them myself in a way differentiated (subtly) from 'if cond: raise SomeException'.
I honestly don't know how Ivan has avoided seeing these. Giving up this useful construct would feel about the same as depreciating 'finally'. Yes, Python would be Turing complete without it, and you could work around it being missing... But why?! On Nov 27, 2017 11:12 PM, "Ivan Pozdeev via Python-ideas" < python-ideas@python.org> wrote: 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/
