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

Eloi Gaudry Eloi.Gaudry at fft.be
Tue Jun 5 11:28:21 EDT 2018


They are basically the same thing, with one difference being that runtime_assert would be used for extension mainly, and switchable on/off without using -o flag on the command line.

Eloi

________________________________
From: Python-ideas <python-ideas-bounces+eloi.gaudry=fft.be at python.org> on behalf of Michel Desmoulin <desmoulinmichel at gmail.com>
Sent: Tuesday, June 5, 2018 3:33:30 PM
To: python-ideas at python.org
Subject: Re: [Python-ideas] Runtime assertion with no overhead when not active

Maybe somebody already answered this, but what's the difference between
this and the keyword "assert", which basically can be stripped of using
"python -o" ?

Le 05/05/2018 à 10:04, Eloi Gaudry a écrit :
>
>     Hi folks,
>
>
>     I intend to add a runtime assertion feature in python. Before
>     submitting a PEP, I am sending a draft to this mailing list to
>     discuss whether it would make sense (above this message). I have
>     actually been using it for the last 2 years and it has proven to be
>     robust and has achieved its primary goal.
>
>
>     Briefly, the idea is to add a new assert that can be switch on/off
>     depending on some variable/mechanism at runtime. The whole point of
>     this assert is that it should not bring any overhead when off, i.e.
>     by avoiding evaluating the expression enclosed in the runtime
>     assert. It thus relies on Python grammar.
>
>
>     Thanks for your feedback.
>
>
>     Eloi
>
>
>
>
>
>
>
>
>
>
>
>     Abstract
>
> This PEP aims at offering a runtime assert functionnality, extending the
> compiletime assert already available.
>
>
>     Rationale
>
> There is no runtime assert relying on python grammar available. For
> diagnostics and/or debugging reasons, it would be valuable to add such a
> feature.
>
> A runtime assert makes sense when extra checks would be needed in a
> production environment (where non-debug builds are used).
>
> By extending the current python grammar, it would be possible to limit
> the overhead induces by those runtime asserts when running in a non
> "assertive" mode (-ed). The idea here is to avoid evaluating the
> expression when runtime assertion is not active.
>
> A brief example why avoiding evaluating the expression is needed to
> avoid any overhead in case the runtime assert should be ignored.
>
> ::
>
> runtime_assert( 999 in { i:None for i in range( 10000000 ) } )
>
>
>     Usage
>
> ::
>
> runtime_assert( expr )
>
> #would result in if expr and runtime_assert_active:
>
> print RuntimeAssertionError()
>
>
>     Implementation details
>
> There is already an implementation available, robust enough for
> production. The implementation is mainly grammar based, and thus the
> parser and the grammar needs to be updated:
>
>   * Python/graminit.c
>   * Python/ast.c
>   * Python/symtable.c
>   * Python/compile.c
>   * Python/Python-ast.c
>   * Python/sysmodule.c
>   * Modules/parsermodule.c
>   * Include/Python-ast.h
>   * Include/graminit.h
>   * Include/pydebug.h
>   * Grammar/Grammar
>   * Parser/Python.asdl
>   * Lib/lib2to3/Grammar.txt
>   * Lib/compiler/ast.py
>   * Lib/compiler/pycodegen.py
>   * Lib/compiler/transformer.py
>   * Lib/symbol.py
>   * Modules/parsermodule.c
>
>
>     References
>
> [1]
>
>
>
> PEP 306, How to Change Python's Grammar
> (http://www.python.org/dev/peps/pep-0306)
>
>
>     Copyright
>
> This document has been placed in the public domain.
>
>
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180605/1a05ee37/attachment-0001.html>


More information about the Python-ideas mailing list