Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Idea: Do not load libpython when precompiling

Offen
  • Stimmt etwas nicht?
#701 2 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@cjdoris arbeitet bereits daran.

Seit 23.10.2025.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

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).

Vorherrschende Sprache
Julia
Sterne
1.1k
Forks
89
Ø Merge
2 T. 15 Std.
Gemergte PRs (30 T.)
7

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus JuliaPy/PythonCall.jl

Alle Issues in JuliaPy/PythonCall.jl

Ähnliche Issues

Weitere Issues zu Julia

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.