nueva versión de la capa intermedia , que permite que las aplicaciones Python tengan acceso completo a las bibliotecas de clases en el lenguaje Java. Con JPype de Python, puede utilizar bibliotecas específicas de Java para crear aplicaciones híbridas que combinen código Java y Python. A diferencia de Jython, la integración con Java no se logra mediante la creación de una variante de Python para la JVM, sino mediante la interacción a nivel de ambas máquinas virtuales utilizando memoria compartida. El enfoque propuesto no sólo permite lograr un buen rendimiento, sino que también proporciona acceso a todas las bibliotecas de CPython y Java. Código de proyecto licenciado bajo Apache 2.0.
Cambios importantes:
- Se ha agregado un caché a las llamadas a métodos para evitar la resolución de sobrecarga, lo que reduce en gran medida el impacto en el rendimiento de la resolución de métodos, especialmente si se llama a la misma sobrecarga muchas veces, como durante la ejecución del bucle.
- De 4 a 100 veces, dependiendo del tipo de datos, se acelera la transferencia de listas, tuplas y buffers a matrices de primitivas Java. La conversión utiliza un procesamiento optimizado de buffers en memoria, en lugar de la API de secuencia. Cuando se encuentra un búfer de Python, solo se verifica la conversión del primer elemento, ya que estos búferes son homogéneos.
- Operaciones de apagado de procesamiento (implementadas en JPype 1.0.0, pero se omitieron al preparar el registro de cambios). JPype ahora llama a la rutina de cierre de JVM, que intenta salir correctamente. Esto conduce a varios cambios de comportamiento. Los subprocesos que no están en segundo plano (llamadas de proxy) ahora pueden mantener abierta la JVM hasta que finalicen. Las llamadas de proxy procesarán el apagado hasta que se complete la llamada, pero recibirán un mensaje de cancelación. Los archivos ahora se cierran correctamente y se descargan en el disco si los subprocesos manejan la excepción como se esperaba. Se ejecutan finalizadores y ganchos de limpieza de recursos. Cuando se generan subprocesos, se llaman los ganchos AtExit. A través del demonio, se implementa la conexión automática de subprocesos cuando se utiliza la JVM de Python. El código defectuoso que no puede manejar adecuadamente la limpieza de subprocesos probablemente se bloqueará cuando se ejecute el apagado. Puede encontrar documentación adicional en el manual del usuario.
- El contenedor de Throwable recibió un contenedor de Objeto en lugar del resultado esperado, lo que provocó conversiones extrañas de las clases de Python.
- Se corrigieron errores tipográficos en el sistema de importación que resultaban en el error '»jname» no encontrado'.
- Se aseguró de que "^C" se promocionara correctamente en KeyboardInterrupt.
- Se solucionó el problema con los símbolos desde Python 3.5.3. PySlice_Unpack se introdujo en una versión de parche posterior (3.5.4) y no debería haberse utilizado.
- Se corrigió un error con numpy.linalg.inv que provocaba un bloqueo. El problema se debe a la comunicación de subprocesos entre la JVM y algunas versiones numerosas. La solución propuesta es llamar a numpy.linalg.inv antes de iniciar la JVM.
Fuente: opennet.ru