How to choose between `PyCall.jl` and `PythonCall.jl`?

General Usage
,
1

I noticed there exist at least two packages PyCall.jl and PythonCall.jl for calling Python from Julia. What’s the difference between them? Which is better for a new user to choose? Thanks!

2

I personally use PythonCall but I couldn’t remember why, so I looked it up :rofl:

https://cjdoris.github.io/PythonCall.jl/stable/pycall/#Comparison

4 Likes
3

Thank you! Your choice is a very valuable reference for me. :smiley:

4

I would say new users should mostly use PythonCall.jl.
Firstly because better package management (PyCall.jl uses 1 Conda enviroment for everything, which is a bit of a nightmare if you have lots of different projects.).
But secondly, based on some comments from @stevengj (the maintainer of PyCall.jl) that PythonCall made a bunch of design choices that if there was to be a PyCall v2.0 he would have liked to change to do (but that he won’t as its too breaking).

9 Likes
5

Especially when working on different projects (and machines), I found CondaPkg together with PythonCall very useful.

2 Likes
6

Another vote for PythonCall from me.

1 Like
7

There are some differences in the details that might make one more attractive. A detailed comparison with benchmarks, something more than everything that’s been written, would be useful. But frankly, given all the TODOs in Julia world, it’s probably not worth the effort.

A few observations

  • PythonCall used to be less flexible. Some of that has been changed for the better (IMO). You can configure some things via env vars. eg you can now avoid downloading things like conda automatically just by loading the package. I did something like this in a package of mine. tkf convinced me to avoid this kind of “magic”. However, I’d like to see a bit more modularity. Might be more work for the maintainer, so I won’t look a gift-horse in the mouth.

  • Do you plan to use it in a private research setting? Or release a package? Or a turnkey application? Making sure PyCall works in various environments programmatically is a ton of work. I wrote a few tools for this. But they are not widely used.

  • You might find the conventions for conversion between python and julia types of one or the other better.

  • The call overhead of the two might differ.

  • In PythonCall it used to be (maye still?) easy to inadvertently get a wrapped object that supports Julia’s iteration protocol. But the iteration is very slow. It might take a while to trouble shoot performance problems. This is not a show stopper. But a difference that you should be aware of. In general, you might find one or the other more ergonomic for your use case.

EDIT: But the big picture is that I (and others) expect PythonCall to become the go-to package and receive more development attention, and for PyCall to continue only in maintenance mode. In writing PythonCall, the author solved a major problem in Julia interop.

6 Likes