lupa icon indicating copy to clipboard operation
lupa copied to clipboard

Identity of wrapped Lua objects

Open astoff opened this issue 1 year ago • 0 comments

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
False

There 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)
True

I 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 == t2 in 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 == t2 and hash(t1) == hash(t2).

astoff avatar Oct 28 '23 11:10 astoff