diff options
Diffstat (limited to 'guide/_sources')
| -rw-r--r-- | guide/_sources/interpreter.rst.txt | 6 | ||||
| -rw-r--r-- | guide/_sources/porting.rst.txt | 42 |
2 files changed, 42 insertions, 6 deletions
diff --git a/guide/_sources/interpreter.rst.txt b/guide/_sources/interpreter.rst.txt index 272b463..c29a62a 100644 --- a/guide/_sources/interpreter.rst.txt +++ b/guide/_sources/interpreter.rst.txt @@ -160,8 +160,7 @@ a stand-alone Python interpreter, it supports bidirectional interaction between Python and Java libraries. Jython development is very slow paced, and it is currently bound -to Python 2.7. Gentoo does not support building packages for Jython -anymore. The interpreter is still provided as ``dev-java/jython``. +to Python 2.7. Gentoo does not provide Jython anymore. IronPython_ is an implementation of Python for the .NET framework. Alike Jython, it supports bidirectional interaction between Python @@ -170,8 +169,7 @@ packaged in Gentoo. Brython_ is an implementation of Python 3 for client-side web programming (in JavaScript). It provides a subset of Python 3 standard -library combined with access to DOM objects. It is packaged in Gentoo -as ``dev-python/brython``. +library combined with access to DOM objects. MicroPython_ is an implementation of Python 3 aimed for microcontrollers and embedded environments. It aims to maintain some compatibility diff --git a/guide/_sources/porting.rst.txt b/guide/_sources/porting.rst.txt index 3b79f47..b4b0914 100644 --- a/guide/_sources/porting.rst.txt +++ b/guide/_sources/porting.rst.txt @@ -53,10 +53,42 @@ Behavior after:: .. _django PR#14349: https://github.com/django/django/pull/14349 +Experimental Python implementations +=================================== + +PyPy +---- +PyPy is using JIT to run Python code which can result in significant +performance improvements in some workflows, but it could also penalize +other programs. + +In particular, calls to compiled extensions can penalize PyPy severely. +For this reason, it is generally recommended to skip building "speedup" +extensions for PyPy — in fact, upstream build systems frequently do that +automatically. A common approach is to combine checks for PyPy with +``native-extensions`` USE flag: + +.. code-block:: bash + + python_compile() { + if ! use native-extensions || [[ ${EPYTHON} == pypy3 ]]; then + local -x MULTIDICT_NO_EXTENSIONS=1 + fi + + distutils-r1_python_compile + } + +However, this does not imply that Python packages largely based +on C extensions should not be marked for PyPy3 compatibility. +For example, while packages such as Pandas can be less performant +under PyPy, they could be used as a part of larger program that overall +benefits from running under PyPy. + + .. index:: freethreading Freethreading CPython versions -============================== +------------------------------ CPython is used the so-called "global interpreter lock" to prevent multiple threads from executing Python code simultaneously. It was designed like this to simplify implementation, but at the cost of @@ -86,7 +118,13 @@ whether a C extension supports freethreading mode, grep the code for ``Py_MOD_GIL_NOT_USED``. CPython will also verbosely warn upon importing extensions without this support. -In general, do not add ``python3_13t`` to ``PYTHON_COMPAT`` +In general, do not add ``python3_13t`` to ``PYTHON_COMPAT`` in leaf +packages, unless they make use of multithreading and have real gain +from freethreaded versions — otherwise, it may actually be slower than +the regular variant. + +For dependency packages, add ``python3_13t`` only after explicitly +testing that the package in question works. Do not add it if the package in question installs extensions that do not support freethreading. This would penalize the setup, prevent proper testing and therefore defeat the purpose of separately specifying this target. |