New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Working with type instabilities, coming from PyJulia #441
Comments
Okay it seems like this was all explained here: https://juliapy.github.io/PythonCall.jl/stable/pythoncall/#Conversion-between-Julia-and-Python and is the expected behavior. So I simply need to run a It would be great if this could be the default behavior instead of |
See also https://juliapy.github.io/PythonCall.jl/stable/juliacall-reference/#juliacall.convert, which allows you to convert the object Python-side before passing it into the Julia function. |
Thinking more hard about the default conversion behaviour of containers is on the roadmap for PythonCall/JuliaCall v1.0. The original intent was to use wrapper types for speed and mutability, but this forces the eltype to be |
I think converting lists to vectors by default would be the better option for a variety of reasons. The inexperienced users are the ones most likely to shoot themselves in the foot by passing mutable objects to a Julia call, and also the least aware of the issues caused by type instability. Experienced users will find a way to mutate lists if they need to so I think the default interface should just create a vector. |
@cjdoris Is there an automatic way to force type conversions when passing Python objects to methods? Or, in other words, is there a way to automatically convert Python arguments to their Julia counterparts?
For example I am running into this issue right now when I pass a list of integers:
which causes some issues as now
f
is unaware of the element type of this vector.However, in PyJulia, arguments seem to somehow get converted automatically:
Is there a way to get this same behavior in PythonCall?
Possibly related to #439
The text was updated successfully, but these errors were encountered: