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@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
