[Python-ideas] Runtime assertion with no overhead when not active

Eloi Gaudry Eloi.Gaudry at fft.be
Thu May 17 03:46:41 EDT 2018


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?
>> 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 ?



More information about the Python-ideas mailing list