Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Re #617, this extends the functionality of jlwrap. I'll explain this a bit more below, but first some side notes:
libpython/
. In particular, there are some auto-generated wrappers around many functions and global objects from libpython. Structs which mirror libpython structs are also there. I have used the naming convention from Julia and prepended "C" to all the names. For example, what wasPyObject_struct
I have taken the liberty to renameCPyObject
.libpython/extensions.jl
contains extensions to the C API, for example allowing conversion from Julia strings to Python strings and back. In particular, there isCPyObject_From(x)
which converts from julia to python. Then simplyPyObject(x) = PyObject(CPyObject_From(x))
(seeconversions.jl
).pystr
) I have re-implemented things using the C API instead of the higher level PyCall API, because this is more direct, invokes Julia's exception handler less, and is less susceptible to changes in the PyCall API, in particular with changes to automatic conversion.Aside from the above, the file
jlwrap.jl
contains the main piece of the implementation.CPyJlWrapObject
.CPyJlWrap*_Type
, whereCPyJlWrap_Type
is the root. The functionality of each type should best represent the translation between Julia and Python semantics, so for example an object of typeCPyJlWrapBufferedIO_Type
translates JuliaBase.IO
semantics to pythonio.BufferedIO
semantics.PyObject(CPyJlWrap_New(t, x))
wheret
is the type andx
is the Julia value being wrapped.PyObject(CPyJlWrap_From(x))
(alternativelypyjlwrap(x)
) selects the type appropriately based on the type ofx
, so numbers get wrapped with some subtype ofCPyJlWrapNumber_Type
, etc.numbers
,io
andcollections.abc
. The types are all registered to the corresponding ABC, so for examplejlwrap(3//2)
is an instance ofnumbers.Rational
. Thenumbers
andio
interfaces are fully implemented (I think). Thecollections.abc
interface is less complete.Things to do:
collections.abc
interface.Array
orString
etc.