You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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==t2False
I'd suggest that calling t1 == t2 in Python should be equivalent to:
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).
The text was updated successfully, but these errors were encountered:
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:
There is a workaround, which is to define:
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:I'd suggest that calling
t1 == t2
in Python should be equivalent to: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
andhash(t1) == hash(t2)
.The text was updated successfully, but these errors were encountered: