You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@lpython decorator (Interface with Python (CPython) #703): get it working for arrays and simple types, and allow importing other LPython compiled packages from within it
Add the @pythoncall decorator to create an "interface" for any Python function (in some Python module), similar how @ccall works, but for Python: Interface with Python (CPython) #703 (comment), Interface with Python (CPython) #703 (comment); this will be implemented by creating BindPython ABI (next to BindC), and then in the backends we implement the conversion; I would start with the C backend, where you add logic for BindPython (in FunctionCall ASR node) and generate C code that calls the Python C/API to import a given module, find the function, convert all arguments and call it
Add @pythoncallable decorator which exposes an LPython function to CPython (similar to @ccallable)
The demo using @lpython will be faster than other Python compilers (lists, dicts, some basic things like arrays and loops), this must be done via the C backend
some LLVM backend demos: lists, dicts and arrays, anything where we are fast
Add demo of using @pythoncall and @pythoncallable, via the C backend
Website with documentation
Blog post(s)
The text was updated successfully, but these errors were encountered:
The next step is to lift the Python interoperability from C to ASR (see #1996) for both @pythoncall and @pythoncallable, this will make it work in all our backends. It should transform BindC functions into directly calls to Python C/API, by probably having some module with the C/API interfaces and then calling them appropriately, all in ASR.
To deliver LPython as an MVP, I think the bare minimum is:
@lpython
decorator (Interface with Python (CPython) #703): get it working for arrays and simple types, and allow importing other LPython compiled packages from within it@pythoncall
decorator to create an "interface" for any Python function (in some Python module), similar how@ccall
works, but for Python: Interface with Python (CPython) #703 (comment), Interface with Python (CPython) #703 (comment); this will be implemented by creatingBindPython
ABI (next to BindC), and then in the backends we implement the conversion; I would start with the C backend, where you add logic forBindPython
(in FunctionCall ASR node) and generate C code that calls the Python C/API to import a given module, find the function, convert all arguments and call it@pythoncallable
decorator which exposes an LPython function to CPython (similar to@ccallable
)@lpython
will be faster than other Python compilers (lists, dicts, some basic things like arrays and loops), this must be done via the C backend@pythoncall
and@pythoncallable
, via the C backendThe text was updated successfully, but these errors were encountered: