[FR] PythonPlot/PythonCall alternative to PyPlot/PyCall

[stevengj]

At some point, it might be good to have support for Matplotlib via PythonCall.jl as an alternative to via PyCall.jl, since people are starting to use the former in many cases.

I've mostly ported PyPlot to PythonCall in https://github.com/stevengj/PythonPlot.jl (not yet registered) and it seems to work, but I've only lightly tested it. You should be able to straightforwardly port your existing pyplot.jl backend to it — the biggest differences are due to PythonCall vs PyCall, e.g. ~~o."foo" just becomes o.foo~~ (you can still use o."foo"), and you have to explicitly request conversion to Julia types if needed.

Maybe not an immediately urgent need, but I wanted to file an issue to track any efforts on this.

cc @cjdoris

[stevengj]

Alternatively, since you only need a low-level interface to matplotlib, you could call matplotlib.pyplot directly via PythonCall.jl and only borrow small pieces of PythonPlot.jl as needed.

[isentropic]

Do you think there would be any TTFP improvement?

[stevengj]

Do you think there would be any TTFP improvement?

Not currently. Right now, PyCall and PyPlot are significantly faster to load than PythonCall and PythonPlot. The following timings are each from a separate fresh Julia session:

julia> @time using PyCall
  0.830682 seconds (1.00 M allocations: 64.378 MiB, 1.38% gc time, 70.07% compilation time)

julia> @time using PyPlot
  3.577596 seconds (6.16 M allocations: 351.258 MiB, 4.06% gc time, 56.61% compilation time)

julia> @time using PythonCall
  4.630488 seconds (5.04 M allocations: 280.009 MiB, 2.14% gc time, 89.32% compilation time)

julia> @time using PythonPlot
  8.502762 seconds (11.42 M allocations: 638.482 MiB, 2.79% gc time, 75.06% compilation time)

Maybe this will change in the future, of course.

PythonCall has the advantage of letting you isolate different Python environments for different Julia projects, and also makes different choices on type conversions than PyCall.