Idea: Do not load libpython when precompiling
维护者通常 1 天内回复
@cjdoris 已经在做这个了。
开始于 2025年10月23日。
评估
这个 Issue 还没有评估数据。
描述
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 asPyLong_AsLongLongetc)
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).
- 主要语言
- Julia
- 星标
- 1.1k
- 派生
- 89
- 平均合并
- 2 天 15 小时
- 30 天内合并 PR
- 7
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
JuliaPy/PythonCall.jl 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 55/100
JuliaPy/PythonCall.jl#828 · 7 条评论 ·
维护者通常 1 天内回复
-
bug
难度 4/5 3-5 天 新手友好度 48/100
JuliaPy/PythonCall.jl#809 · 2 条评论 ·
维护者通常 1 天内回复
-
enhancement
难度 5/5 一周以上 新手友好度 35/100
JuliaPy/PythonCall.jl#805 · 4 条评论 ·
维护者通常 1 天内回复
-
enhancement
难度 3/5 1-2 天 新手友好度 68/100
JuliaPy/PythonCall.jl#796 ·
维护者通常 1 天内回复
-
enhancement
难度 5/5 一周以上 新手友好度 25/100
JuliaPy/PythonCall.jl#790 ·
维护者通常 1 天内回复
查看 JuliaPy/PythonCall.jl 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
oxfordcontrol/COSMO.jl#211 ·
-
documentation
难度 2/5 半天 新手友好度 65/100
维护者通常 6 天内回复
-
Out-of-place JLArray/GPU problem with VectorContinuousCallback scalar-indexes (callback cache built with CPU zeros)可能已有人在做 @ChrisRackauckas-Claude 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 74/100
SciML/OrdinaryDiffEq.jl#4813 ·
维护者通常 1 天内回复
-
ARKODE: callbacks that modify `u` throw MethodError on reinit可能已有人在做 @devmotion 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 79/100
SciML/Sundials.jl#575 ·
-
难度 1/5 1 小时以内 新手友好度 78/100
维护者通常 1 天内回复