:experimental: :toc: include::partial$entities.adoc[] = The Python Programming Language Python provides memory safety by default, so low-level security vulnerabilities are rare and typically needs fixing the Python interpreter or standard library itself. Other sections with Python-specific advice include: * xref:tasks/Tasks-Temporary_Files.adoc#chap-Defensive_Coding-Tasks-Temporary_Files[Dealing with temp files] * xref:tasks/Tasks-Processes.adoc#sect-Defensive_Coding-Tasks-Processes-Creation[Creating Safe Processes] * xref:tasks/Tasks-Serialization.adoc#chap-Defensive_Coding-Tasks-Serialization[Serialization and Deserialization], in particular xref:tasks/Tasks-Serialization.adoc#sect-Defensive_Coding-Tasks-Serialization-Library[Library Support for Deserialization] * xref:tasks/Tasks-Cryptography.adoc#sect-Defensive_Coding-Tasks-Cryptography-Randomness[Randomness] == Dangerous Standard Library Features Some areas of the standard library, notably the `ctypes` module, do not provide memory safety guarantees comparable to the rest of Python. If such functionality is used, the advice in xref:programming-languages/C.adoc#chap-Defensive_Coding-C[Defensive Coding in C] should be followed. == Run-time Compilation and Code Generation The following Python functions and statements related to code execution should be avoided: * `compile` * `eval` * `exec` * `execfile` If you need to parse integers or floating point values, use the `int` and `float` functions instead of `eval`. Sandboxing untrusted Python code does not work reliably. == Sandboxing The `rexec` Python module cannot safely sandbox untrusted code and should not be used. The standard CPython implementation is not suitable for sandboxing.