My choice of words might not be the best, yes. I do see to different meanings and/or context for the historical assert and the one I propose:
1/ the first one would be something saying that, as a developer, when writing >>> assert (expr) in my python code, I mean that all my unit tests and real life tests I could think of should succeed the test. I do mean "don't go further, I might not know where you come from or where you intend to go or why you are behaving as such, but you failed to meet this and/or this criteria/condition". 2/ the second one is there to activate some other checks, not while developing, just at runtime when the user uses my extension and want to get some diagnostics/enforcing checks to happen, because he/she is using something I couldn't think of in the first place, something that would not have been checked before. Yes, those checks might be considered as identical in a language sense, but then : as an extension/interpreter writer, why should I only rely on the debug assert available today? Why would it not make sense to offer another assert, semantically different, aiming at runtime checks issues and this time where control is indeed by the consumer/the extension? -----Original Message----- From: Python-ideas <python-ideas-bounces+eloi.gaudry=fft...@python.org> On Behalf Of Chris Angelico Sent: Tuesday, May 8, 2018 7:38 PM To: python-ideas@python.org Subject: Re: [Python-ideas] Runtime assertion with no overhead when not active On Wed, May 9, 2018 at 1:51 AM, Eloi Gaudry <eloi.gau...@fft.be> wrote: > I think that is a difference between: > - the current 'assert' which usage seems (to me) to focus on > development correctness (I think of it as the C-assert enabled in any > C program in debug build ) > - the runtime_assert that I submitted on the list, which would be > focusing on usage correctness (hence runtime), and easily disabled at > runtime (when the python command line options parsing is not an > option, for instance when the python interpreter is not python itself > and/or when the consumer/extension wants to behave differently). What's the difference between "development correctness" and "usage correctness"? Does the latter depend on user input at run time? I still don't understand the distinction you're trying to make here. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
