PyCall.jl py string equivalents

[icweaver]

Would it make sense to have a version of PyCall.jl's py string macros? The use case I see for this is wrapping your pre-written Python code and calling it from Julia, so maybe something like this:

I know nothing about macros and namespace stuff, so could be totally off here!

[cjdoris]

We already have @pyeval and @pyexec: https://cjdoris.github.io/PythonCall.jl/stable/pythoncall/#PythonCall.pyeval

They're a little more verbose than PyCall's @py_str but also more general because you can extract values out of exec calls and convert the result types.

[cjdoris]

Though personally I don't think it's a great hardship to just put a global statement at the top of @pyexec.

[icweaver]

I wasn't aware of that distinction between pyeval and @pyeval, thanks for pointing that out! I am struggling to implement this in the toy example, and think I am doing it in a really roundabout way:

@pyexec """
global py_sqrt
global np

import numpy as _np
np = _np

def _py_sqrt(x):
	return np.sqrt(x)
py_sqrt = _py_sqrt
"""
py_sqrt(x) = @pyeval("py_sqrt")(x)

Though personally I don't think it's a great hardship to just put a global statement at the top of @PYEXEC.

haha, fair enough. I'm sure that this will feel like less of a hassle once I iron out my usage in the above example

[cjdoris]

I think this does what you want:

global np, py_sqrt
import numpy as np
def py_sqrt(x):
    return np.sqrt(x)

[icweaver]

ugh, I guess that's what I get for only trying things out in a Pluto notebook. It turns out that py_sqrt(x) = @pyeval("py_sqrt")(x) needs to be in the same cell for py_sqrt(3) to work, otherwise it throws a NameError for the function, hence my over-complicated workaround above X(

That's my bad, thanks for your patience. I'm totally happy with the above and think having a global version of @pyexec would just be icing on the cake, but definitely not super critical!

[cjdoris]

Happy to help!