Christopher Rowley

I can reproduce your issue, and have pushed a fix to main. Please try it out with `pkg> add PythonCall#main`.

The `__init__()` function is not called until after the module is loaded (and PythonCall is already initialised) which is too late. You need to set the env var before loading...

When I said "you need to set the env var before loading the package" I meant before loading the WVZPythonExt package. You can't reliably do this from within a package...

Yep, having PythonCall configurable with Preferences is on the to-do list. I don't see why a package should be setting the CondaPkg backend though? Surely this depends on the user...

In Julia, PythonCall already has custom stacktrace printing so that the Python stack is in the same order as Julia: ``` julia> @pyexec """ global pyinner, pyouter def pyinner(): raise...

But yes, you're right that from Python, the Julia stack is printed in reverse. This is because custom stack printing has not been implemented on that side, so just uses...

Thanks for the PR! A couple of comments: PythonCall avoids relying on anything other than the Python standard library - so `Py(::Period)` should not be converted to a `numpy.timedelta64` (if...

That would indeed be nice. And should be much easier than the Pandas case because the column types are better defined in Polars. I'm rewriting the conversion internals at the...

This sort of thing is often caused by conflicting versions of libraries being loaded - in this case presumably it's Python and Matlab conflicting. I'd recommend starting Julia like `LD_DEBUG=libs...

Short answer: `juliacall.convert`. Long answer: I got conversion right in PythonCall but wrong in JuliaCall. In your example, you start with a python `tuple` of `float`s, which is converted to...