Best Practice for Writing Packages that Depend on PythonCall

[mestinso]

In the latest documentation, the following approach seems to be recommended (or at least documented):

const foo = Ref{Py}()
function __init__()
  foo[] = pyimport("foo")
end

However, most packages i'm seeing (such as Faiss.jl or PythonPlot.jl) do things the following way:

const foo = PythonCall.pynew()
function __init__()
    PythonCall.pycopy!(foo, pyimport("foo"))
end

With that in mind, is there any specific guidance regarding which approach is recommended and pros/cons? Is it worth mentioning anything in the documentation about this?

The main thing I would note is that the first approach appears to be requiring the brackets on foo[] when it is used, which is a little annoying, but maybe not the worst thing...

[cjdoris]

The pycopy! method used to be recommended, but pynew and pycopy! are unsafe functions when used incorrectly so it's best to avoid them. I'll probably undocument them in PythonCall 1.0.

There should be no perceptible difference between the two methods, other than the syntax. The Ref version does have one extra layer of pointer indirection, so will technically be slower, but it will be unnoticeable unless you're accessing the variable 100 million times in a second.

There's also the @pyconst way in the docs:

foo() = @pyconst pyimport("foo")

[gyansinha]

Is

foo() = @pyconst pyimport("foo")

a substitute for

const foo = Ref{Py}()
function __init__()
  foo[] = pyimport("foo")
end

Would also be useful to clarify how all this would work with
Dont use init #300

[cjdoris]

Other than the syntax (foo() vs foo[]) the only major difference is that if the import fails, then with one way it fails during module __init__ and the other way it doesn't fail until foo() is called the first time.

I haven't considered #300 deeply enough yet to know it's ramifications.