[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?
> 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 ?
More information about the Python-ideas
mailing list