-
-
Notifications
You must be signed in to change notification settings - Fork 143
Description
To motivate this issue, consider the problem of recursively converting Lua tables (possibly with self-references) to Python lists.
This requires knowledge of the identity/memory location of the Lua objects (as opposed to their wrappers). Or at least it requires hashing and comparison by identity. This is not possible out-of-the-box:
>>> from lupa import LuaRuntime
>>> lua = LuaRuntime()
>>> t1, t2 = lua.execute("t={}; return t, t")
>>> t1 is t2
FalseThere is a workaround, which is to define:
>>> lua_id = lua.eval("function(o) return tonumber(string.format('%p', o)) end")
>>> lua_id(t1) == lua_id(t2)
TrueI would like to suggest that and something equivalent to the above function be defined in Lupa (using Lua's C API and no recourse to string formatting, of course).
Still related to this:
-
In the above code snippet, it's of course not a bug that
t1 is not t2. This, however, seems like a problem to me:>>> t1 == t2 False
I'd suggest that calling
t1 == t2in Python should be equivalent to:>>> lua.eval("function(t1, t2) return t1 == t2 end")(t1, t2) True
-
Somewhat surprisingly, wrapped Lua objects are hashable (this is inconsistent with Python's principle that mutable objects are not hashable — although, now that look more closely, closures are also hashable in Python despite being mutable...). I have no strong opinion about whether or not Lua wrappers should be hashable, but if they are, then surely it should hold that
t1 == t2andhash(t1) == hash(t2).