On Thu, 2018-05-17 at 03:09 +1000, Steven D'Aprano wrote: > On Wed, May 16, 2018 at 01:27:50PM +0000, Eloi Gaudry wrote: > > On Wed, 2018-05-16 at 21:15 +1000, Steven D'Aprano wrote: > > > On Wed, May 16, 2018 at 08:29:00AM +0000, Eloi Gaudry wrote: > > > > Is there some interest in the proposal or should I finally > > > > close > > > > this > > > > thread ? > > > > > > I'm definitely interested in the concept, not the suggested > > > syntax > > > or semantics. > > > > Would you briefly describe a syntax that would better fit this > > concept > > ? > > The syntax is the minor point: you give is an ungainly name, > "runtime_assert", and your proposed PEP shows it requiring > parentheses > as if it were an ordinary function. > > The bigger problem is the semantics. As I already said in an earlier > email, you don't explain what "runtime_assert_active" is (is it a > per-module global variable? a single application-wide super-global? > a > local variable? something else?) or how we are supposed to set it. I proposed to have several ways to set it (see previous answers) : one would be extension based and the other would rely on having a builtin value that one would be able to change using a set function of the python core.
> That > too is an ungainly name, and the fact that there's only *one* such > flag > (whether it is per module or not) makes this proposal useless for my > needs. I agree with you on this : the main issue with my proposal is that having only one assert (function with deferred evaluation) more is not enough : we would need to cover several other scenarii such as an extension wanting to activate its own asserts without activating other extensions checks. > Another problem is that your runtime_assert *prints* the error > message instead of raising an exception, and there's no way to > customise the message. It actually raise an AssertionError. I do agree that it should allow to set/display a message though. > > But the most important reason is that I'm not really interested in > adding a new keyword for this. I would much prefer to explore ways > to > allow ordinary functions to receive arguments and be able to delay > evaluation of those arguments until needed. What would then be solution for implementing the runtime_assert with the current python api ? A lambda ? _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/