BTW, don't you think that the example I wrote in the first example
should return the value to python instead of raising? I thought it should.
On 17/01/2016 19:38, Sergey Dobrov wrote:
On 17/01/2016 13:43, Stefan Behnel wrote:
Hi,Hi, thanks for the great project!
thanks for the report.
Sergey Dobrov schrieb am 16.01.2016 um 13:05:You see, I'm using lupa with an existing project in lua, and that
I faced the following problem using lupa:Not impossible. You can always wrap ypur Python code in a try-except (or in
lua = LuaRuntime(unpack_returned_tuples=True)
x = lua.eval('function(p) local r, err = p(); return r, err end')(lambda:
5/0)
This code raises ZeroDivisionError in python while I was expecting it to
return (False, "error during Python call").
The problem is that lupa reraises any unhandled python exception
regardless if it was intercepted by lua or not. That makes problems when
lua code is using python code and trying to make sure it does not fall.
I understand that this was invented to intercept python exceptions as
usual but it certainly makes some things impossible.
a function wrapper that uses that) and return an error value instead of
forwarding the exception.
project is going to call python code and it does expect code to fall
when it's falling and not returning the error.
And it looks a very right decision to me, by the way.
Lua calls a function which turns to be a python function but Lua code
I think it kind of impossible to know if lua called us in protected modeDon't know, but the problem is that the raised exception remains alive and
to decide not to reraise?
needs to either go somewhere or die explicitly. I think the current
behaviour is the best standard behaviour, but given that it's not difficult
to catch exceptions in Python code, I'm not sure I'd complicate Lupa's
interface for this.
does not know about that, it's an ordinary function for it. So it must
fall if it falls and even if I catch an error in python what should I
return? There is no answer, any return value will be treated as a
success while it should have been fail.
I'm implementing a module for prosody which allows to run modules
In this case I could suggest to make some flag to not reraise andCould you describe your use case a little deeper to motivate that this
probably add the exception to LuaError instead to be checked later, if
needed?
would be the desired solution?
written in python using lupa. So I can't change prosody code to know
that there are some magic return values that must be treated as errors.
Code must fall in lua when it falls and, if lua intercepted, I should
not get the exception in python because otherwise it breaks the
prosody's main loop and new queries start to fail to be processed, which
is not stable behaviour of course, and, if we won't have a solution
inside lupa I'll have to fork it, which is not too good because the
change is not that big actually.
Yeah, the module is open-sourced: https://github.com/jbinary/prosodypy
Thanks.
Stefan