python stack frames not initialized (inspect.currentframe() fails) about pycall.jl HOT 10 OPEN

Hmm, it seems like this might be a bug in ggplot, since there are no local variables if Python is embedded.... Or it could be a bug in inspect, since you'd still want it to define an empty f_locals in this case.

from pycall.jl.

Hmm,

using PyCall
@pyimport inspect
inspect.currentframe()

gives

PyError (PyObject_Call) <type 'exceptions.ValueError'>
ValueError('call stack is not deep enough',)

Similarly

@pyimport sys
sys._getframe()

gives a ValueError('call stack is not deep enough',), whereas in python I get:

>>> import sys
>>> sys._getframe()
<frame object at 0x106781b90>

So it seems that this is not a property of inspect, but rather a consequence of embedded Python not having a call stack before you call a function. I wonder if there is some way to "fake" this?

(But I still think that ggplot and/or inspect shouldn't depend on this.)

from pycall.jl.

So there are no quick solutions?

from pycall.jl.

You could open an Bugreport asking the patsy developers to work around in such situations.

from pycall.jl.

You could try to change the line to return cls([<empty list?>, <empty list?>], _ALL_FUTURE_FLAGS) (I'm not sure what type frame.f_locals and frame.f_globals are) the and see if that would make it work.

That "environment" is used in ggplot to evaluate things like ggplot.aes(x="x+y",y="np.log(assets)"). So if julia calls have no access to the underlying functions, you can only use column names (which are added to the environment in a later step).

Another obstacle could be that ggplot expects data as pandas DataFrames. Not sure how that library works in Julia (I've not yet used Julia).

from pycall.jl.

Try using pyeval instead of pycall

from pycall.jl.

@malmaud, good suggestion. Looking at the source code for PyEval_EvalCodeEx, I see that it indeed creates a frame while it is executing:

julia> pyeval("i.currentframe()", i=PyCall.inspect)
PyObject <frame object at 0x3223793a0>

from pycall.jl.

In principle, it looks like PyCall could create its own stack frame by doing something like this internal function. In practice, I'm a bit leery of relying on undocumented internals like this, since ordinary Python code should not rely on inspect.currentframe() existing, and one can use pyeval as a workaround for the rare exceptions.

from pycall.jl.

I think this issue should be fixed in upstreams. FYI here is my PR to matplotlib for fixing this issue: matplotlib/matplotlib#12771. (Maybe it's faster to get a fix if you include an example when reporting it?)

from pycall.jl.

Consider adding this to the error message:

Embedded Python does not have a stack frame. Use pyeval as a workaround.

It'll save some confusion.

from pycall.jl.