I believe it does, see in its docs:
Fast non-copying conversion of numeric arrays in either direction: modify Python arrays (e.g.
numpy.ndarray) from Julia or Julia arrays from Python.
Note for PyCall:
Multidimensional arrays exploit the NumPy array interface for conversions between Python and Julia. By default, they are passed from Julia to Python without making a copy, but from Python to Julia a copy is made; no-copy conversion of Python to Julia arrays can be achieved with the
PyArray type below.
Both package allow interopting with all Python libraries, and PyCall has fast(er) startup (and the py string macro, which I kind of miss, done differently in the alternative), other than that I believe PythonCall is the future, already many packages migrating to it from using PyCall (you CAN also use both together, according to the docs, if you do it right), because it has benefits, e.g. for dependency handling and:
Both packages allow conversion of Julia values to Python:
PyObject(x) in PyCall,
Py(x) in PythonCall.
Whereas both packages convert numbers, booleans, tuples and strings to their Python counterparts, they differ in handling other types. For example PyCall converts
list whereas PythonCall converts
juliacall.VectorValue which is a sequence type directly wrapping the Julia value - this has the advantage that mutating the Python object also mutates the original Julia object.
In fact, PythonCall has the policy that any mutable object will by default be wrapped in this way, which not only preserves mutability but makes conversion faster for large containers since it does not require taking a copy of all the data.
PyCall requires numpy to be installed, PythonCall doesn’t (it provides the same fast array access through the buffer protocol and array interface).
In its docs:
Helpful wrappers: interpret Python sequences, dictionaries, arrays, dataframes and IO streams as their Julia counterparts, and vice versa.
Dictionaries are by now ordered in Python, and while I would want them that way in Julia too (I tried to make a PR for that), they are not in Julia, so I’m not sure what happens with either package when converting. This could be a surprise.
Also Julia uses UTF-8 for strings, but Python doesn’t (though allows as a redundant representation), so it can’t be zero-copy when calling Python, until it changes to UTF-8 by default (and only) which I believe is planned. Neither in the other direction, though might be if UTF-8 also used, but I doubt that’s supported, but could be.
I don’t know how classes/object are handled…