# \[ANN\] PythonCall and JuliaCall

**URL:** <https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778>\
**Category:** Package Announcements\
**Tags:** interoperability, python, pythoncall\
**Created:** [February 19, 2022, 10:49pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778 "2022-02-19T22:49:15Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![oschulz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oschulz/32/2998_2.png) [@oschulz](https://discourse.julialang.org/u/oschulz)\
**Post date:** [February 21, 2022, 3:13pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/25 "2022-02-21T15:13:18Z")

</div>

> [@cjdoris](#):
>
> See my earlier reply to marius311.

Oh, sorry, overlooked that - thanks!

---

<div class="post-metadata">

**Author:** ![michikawa07](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/michikawa07/32/34034_2.png) [@michikawa07](https://discourse.julialang.org/u/michikawa07)\
**Post date:** [February 21, 2022, 3:18pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/26 "2022-02-21T15:18:27Z")

</div>

Thank you for your grateful work.  
Can I use syntax of `@pyimport numpy as np` instead of `np = pyimport("numpy")` ?

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [February 21, 2022, 6:49pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/27 "2022-02-21T18:49:28Z")

</div>

> [@michikawa07](#):
>
> Can I use syntax of `@pyimport numpy as np` instead of `np = pyimport("numpy")`?

Note that this was [deprecated some time ago in PyCall](https://github.com/JuliaPy/PyCall.jl/pull/633), and I wouldn’t recommend bringing it back in PythonCall. It doesn’t make the code any shorter or easier to write, and it obscures what is actually going on. The goal is to interoperate with Python code, not necessarily to mimic Python syntax in Julia.

Also, as a general principle, one should be cautious in programming languages/libraries about having multiple syntaxes for the exact same thing, since it can just add confusion and complexity for little benefit.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [February 21, 2022, 7:18pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/28 "2022-02-21T19:18:34Z")

</div>

I’ve just to install `juliacall`.  
At first it hanged forever at the step

```julia
[juliapkg] Locating Julia ^1.6
[juliapkg] Querying Julia versions from https://julialang-s3.julialang.org/bin/versions.json

```

then I decided to kill the `cmd` process and it suddenly started to install Julia

```julia
[juliapkg] WARNING: About to install Julia to C:\programs\miniconda3\julia_env\install.

```

But **why**? I already have Julia installed and don’t want another copy that quite likely will start its own multi GigBytes if I install packages on it.

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [February 21, 2022, 8:15pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/29 "2022-02-21T20:15:13Z")

</div>

> [@Seif\_Shebl](#):
>
> However, I encountered the following error in Julia 1.8.0-DEV when trying the example above and Julia exits immediately:
> 
> ```julia
> julia> using PythonCall
> 
> julia> plt = pyimport("matplotlib.pyplot")
> Python module: <module 'matplotlib.pyplot' from 'D:\\DeepBook\\.julia\\environments\\v1.8\\.CondaPkg\\env\\lib\\site-packages\\matplotlib\\pyplot.py'>
> 
> julia> plt.plot(randn(100))
> qt.qpa.plugin: Could not find the Qt platform plugin "windows" in ""
> This application failed to start because no Qt platform plugin could be initialize
> 
> ```

Can you open an issue please? This should work.

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [February 21, 2022, 8:26pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/30 "2022-02-21T20:26:58Z")

</div>

> [@michikawa07](#):
>
> Can I use syntax of `@pyimport numpy as np` instead of `np = pyimport("numpy")` ?

You can do `@py import numpy as np` (note the space before `import`).

I’ll write about it more another time but `@py` is an experimental macro which maps Julia syntax to its Python equivalent - not just `import` but many other operations too. You can write big blocks of code with it. Despite @stevengj’s concerns above, which are perfectly correct, this macro can sometimes simplify syntax considerably. It can also make tight Python loops much faster by avoiding Julia’s GC.

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [February 21, 2022, 8:39pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/31 "2022-02-21T20:39:48Z")

</div>

> [@stevengj](#):
>
> So I’m quite happy to see people actively working on an alternative re-design, and hope that the existing PyCall and PyPlot are helpful in this process.

If I’m honest, I have partly put off writing this announcement because my intention was never to write “PyCall 2.0” - it started out as an experiment to see if I could do some things differently and just snowballed. I’m extremely pleased and relieved you have such a positive reaction.

Indeed PyCall is a long-established package and I can totally see where some of its quirks come from, historically. The above comparison was never intended as an attack on PyCall - quite the opposite, it’s a brilliant package and (not least) is responsible for some very handy syntax that PythonCall can take full advantage of without the baggage of backwards incompatibility.

I have thought about merging some of the ideas from PythonCall into PyCall - the world doesn’t really need two Python-Julia interop packages - but some of the changes would be so dramatic that, like you say, a totally new package would be no less disruptive.

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [February 21, 2022, 8:41pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/32 "2022-02-21T20:41:34Z")

</div>

> [@joa-quim](#):
>
> it suddenly started to install Julia
> 
> ```julia
> [juliapkg] WARNING: About to install Julia to C:\programs\miniconda3\julia_env\install.
> 
> ```
> 
> But **why**? I already have Julia installed and don’t want another copy that quite likely will start its own multi GigBytes if I install packages on it.

There should be more messages from JuliaPkg explaining why, namely it couldn’t find a compatible version of Julia to use. So either Julia isn’t in your PATH, or it isn’t new enough to work with JuliaPkg which requires Julia 1.6 or above.

Also, aside from the Julia installation itself, it won’t take up any more room on your disk because it will use your usual Julia depot.

---

<div class="post-metadata">

**Author:** ![Seif\_Shebl](https://avatars.discourse-cdn.com/v4/letter/s/eada6e/32.png) [@Seif\_Shebl](https://discourse.julialang.org/u/Seif_Shebl)\
**Post date:** [February 21, 2022, 10:28pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/33 "2022-02-21T22:28:27Z")

</div>

I think I’ll wait for someone else to reproduce before opening an issue. I have multiple installations of Python in different directories and some of them are added to the path and the same thing goes for Julia. I feel that this could confuse the proper installation of PythonCall, so I’ll investigate more and try on another computer before I open an issue. Many thanks.

**Edit:**  
Well, I got it fixed now. The installation was somehow corrupted, I removed the package, then removed everything in the `CondaPkg` folder here: `.julia\environments\v1.8\.CondaPkg` and reinstalled `PythonCall`. When I issued `plt = pyimport("matplotlib.pyplot")`, the package complained about `matplotlib` module not found. I simply did `pip install matplotlib` in Windows terminal inside `.julia\environments\v1.8\.CondaPkg\env\Scripts` and everything worked like a charm. Thank you for the great effort and awesome package.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [February 21, 2022, 11:02pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/34 "2022-02-21T23:02:10Z")

</div>

> [@cjdoris](#):
>
> There should be more messages from JuliaPkg explaining why, namely it couldn’t find a compatible version of Julia to use. So either Julia isn’t in your PATH, or it isn’t new enough to work with JuliaPkg which requires Julia 1.6 or above.

Nope, no messages and I have Julia1.8DEV in the path. Well, don’t know if it makes a difference but what I have in the path is `C:\programs\julia-1.8` where a `julia.bat` takes charge of calling the julia.exe

> [@cjdoris](#):
>
> Also, aside from the Julia installation itself, it won’t take up any more room on your disk because it will use your usual Julia depot.

Good to hear that.

BTW, a better explanation/example on how to call Julia packages from Python would be nice. [As is](https://github.com/cjdoris/PyJuliaPkg), sorry but I just gave up.

---

<div class="post-metadata">

**Author:** ![sqr00t](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sqr00t/32/33545_2.png) [@sqr00t](https://discourse.julialang.org/u/sqr00t)\
**Post date:** [February 22, 2022, 9:47am UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/35 "2022-02-22T09:47:13Z")

</div>

Hiya, I’m just getting back to Julia after a while.

- Built in dependency isolation is great with conda package management!
- Type inference for Python objects also another plus!

However:

- Could there be a more self-explanatory way for Tabular data conversion instead of having pytable and PyTable as separate methods?

---

<div class="post-metadata">

**Author:** ![palday](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palday/32/12640_2.png) [@palday](https://discourse.julialang.org/u/palday)\
**Post date:** [February 22, 2022, 2:43pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/36 "2022-02-22T14:43:29Z")

</div>

Is there a reason not have PyCall 2.0 simply be PythonCall and deprecate the PythonCall name? I haven’t thought about all the implications and whether it even really makes sense for any real-world use cases, but then packages that only use the common subset of features could have a compat entry allowing both “classic” PyCall as well as PythonCall.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [February 22, 2022, 2:59pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/37 "2022-02-22T14:59:34Z")

</div>

Yes, some reasons. PyCall 2.0 will by definition be a breaking change, so the name might as well be PythonCall. It IS possible to use PythonCall with the current PyCall (it’s a non-default option), so that’s one argument for the new name.

At least there’s no way to use some version of a package, such as PyCall, directly or as a dependency, and also another version, through another dependency. I’ve previously thought it might be useful, even for minor versions, just because some dependency is holding back, but I think the right thing is to upgrade to a new (minor) version (and make, trivial usually,PR to packages, as I’ve done, to make it possible to use there latest versions for all packages).

Do any other language, or their package managers allow this?

A good (non-technical) reason is to give @cjdoris (full) credit for his own package, which is a rewrite, not largely (almost not at all?) built on PyCall. He deserves it. PyCall is also really good, and I’m not sure @stevengj would want it taken over (in this way, something similar has happened, I believe, at least once, with Graph.jl). I would advocate he links to PythonCall as an alternative.

---

<div class="post-metadata">

**Author:** ![jlapeyre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlapeyre/32/4514_2.png) [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)\
**Post date:** [February 22, 2022, 3:04pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/38 "2022-02-22T15:04:06Z")

</div>

One difficulty is that it’s not just different features, but the semantics are quite different. And the scope, in terms of aspects of a project that are supported, is quite different. I don’t think just a few compat functions will be sufficient to make PythonCall a drop-in replacements. (I’m not sure if that is what you are suggesting.)

---

<div class="post-metadata">

**Author:** ![Paul\_Soderlind](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paul_soderlind/32/1753_2.png) [@Paul\_Soderlind](https://discourse.julialang.org/u/Paul_Soderlind)\
**Post date:** [February 22, 2022, 4:15pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/39 "2022-02-22T16:15:34Z")

</div>

Just to clarify:

do I avoid getting a new python installation/download if I set (for instance), `JULIA_PYTHONCALL_EXE="C:\\miniforge3\\python.exe"`  
before installing PythonCall?

---

<div class="post-metadata">

**Author:** ![Impressium](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/impressium/32/19575_2.png) [@Impressium](https://discourse.julialang.org/u/Impressium)\
**Post date:** [February 22, 2022, 5:48pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/40 "2022-02-22T17:48:14Z")

</div>

Can one use PythonCall from different threads?

---

<div class="post-metadata">

**Author:** ![marius311](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/marius311/32/3953_2.png) [@marius311](https://discourse.julialang.org/u/marius311)\
**Post date:** [February 22, 2022, 6:44pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/41 "2022-02-22T18:44:09Z")

</div>

I believe so, that’s how it worked for me. Fwiw, PyCall does have a dynamically switchable thing like this too (`PYCALL_JL_RUNTIME_PYTHON`) as long as its the same Python executable that PyCall was built with, just in a different virtualenv. I think PythonCall’s works switching between any Pythons though.

Edit: to be clear, you don’t have to set it before _installing_ PythonCall, you can dynamically switch before any Julia session.

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [February 22, 2022, 8:18pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/42 "2022-02-22T20:18:35Z")

</div>

> [@palday](#):
>
> Is there a reason not have PyCall 2.0 simply be PythonCall and deprecate the PythonCall name?

@jlapeyre and @Palli have made very good points.

One reason to keep them separate is that you can only have one version of a package installed in a project. So if you have a package in your project only compatible with PyCall 1 then you can’t use PyCall 2. PythonCall is sufficiently different that many packages would probably never upgrade, or be very slow to, which kinda pins you down. As it is you can use PythonCall and PyCall together no problem.

Anyway it’s too soon to think about this - PythonCall definitely needs more battle testing first.

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [February 22, 2022, 8:21pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/43 "2022-02-22T20:21:48Z")

</div>

> [@Paul\_Soderlind](#):
>
> do I avoid getting a new python installation/download if I set (for instance), `JULIA_PYTHONCALL_EXE="C:\\miniforge3\\python.exe"`  
> before installing PythonCall?

Yes, selecting an interpreter explicitly opts out of all the automatic dependency handling - nothing will be downloaded. This means installing any required packages is up to you.

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [February 22, 2022, 8:25pm UTC](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778/44 "2022-02-22T20:25:17Z")

</div>

> [@Impressium](#):
>
> Can one use PythonCall from different threads?

Sure if you like segfaults. 😉

Out of the box no, but with manual GIL handling it might work. I’ve never tried.

[Previous page](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778.md?page=1)

[Next page](https://discourse.julialang.org/t/ann-pythoncall-and-juliacall/76778.md?page=3)