Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Idea: Do not load libpython when precompiling

Abierto
  • ¿Algo no está bien?
#701 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@cjdoris ya está trabajando en esto.

Desde el 23/10/2025.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

I propose that when PythonCall is being precompiled, we do not load/initialise libpython. Instead, have shims for the C functions that we use which raise an error or do something else trivial when used.

This means that we do not need to resolve a CondaPkg environment when precompiling, which will make precompilation much faster, simpler and more reliable.

This is breaking because it restricts which Python operations you are allowed to perform during __init__. I suggest that we make all of our shims return errors (clearly stating that you cannot perform this Python operation during module initialisation) except for those which return Python objects, which should return PyPtr(1) (or anything non-NULL) instead.

In particular, we should allow these operations at init:

  • incref, decref, initialize, finalize and other such functions we only use internally
  • pyimport, pygetattr, pygetitem, pyrepr, pystr, pycall, pyhash (always return 1)
  • creation of python objects from nothing, bool, string, number, etc. (Py)
  • GIL handling

And we'll need to disallow the following functions, which require an actual Python interpreter to return reasonable answers:

  • pylen, pyhasattr, pynext (PyIter_Next)
  • pyconvert (such as PyLong_AsLongLong etc)

Concretely, we can make shim functions like this:

shim_error() =
    error("You cannot perform this Python operation during module initialisation.")

shim_PyObject_IsTrue(::PyPtr) = shim_error()
shim_PyObject_Length(::PyPtr) = shim_error()
...

shim_Py_IncRef(::PyPtr) = nothing
shim_PyImport_ImportModule(::Ptr{Cchar}) = PyPtr(1)
shim_PyObject_GetAttr(::PyPtr, ::PyPtr, ::PyPtr) = PyPtr(1)
shim_PyLong_FromLongLong(::Clonglong) = PyPtr(1)
...

And then in init_pointers set the fields of POINTERS like this:

p.PyObject_IsTrue = @cfunction(PyObject_IsTrue_shim, Cint, (PyPtr,))
p.PyImport_ImportModule = @cfunction(PyImport_ImportModule_shim, PyPtr, (Ptr{Cchar},))
...

We should also initialise all the exceptions and other object pointers to PyPtr(1).

Lenguaje dominante
Julia
Estrellas
1.1k
Forks
89
Merge medio
2 d 15 h
PR fusionados (30 d)
7

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de JuliaPy/PythonCall.jl

Todos los issues de JuliaPy/PythonCall.jl

Issues similares

Más issues de Julia

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.