add nested dict support #208
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -104,6 +104,9 @@ def get_attr(obj, name): | |
|
|
||
|
|
||
| class TestLuaRuntime(SetupLuaRuntimeMixin, LupaTestCase): | ||
| def assertLuaResult(self, lua_expression, result): | ||
| self.assertEqual(self.lua.eval(lua_expression), result) | ||
|
|
||
| def test_lua_version(self): | ||
| version = self.lua.lua_version | ||
| self.assertEqual(tuple, type(version)) | ||
|
|
@@ -598,10 +601,16 @@ def test_table_from_bad(self): | |
| self.assertRaises(TypeError, self.lua.table_from, None) | ||
| self.assertRaises(TypeError, self.lua.table_from, {"a": 5}, 123) | ||
|
|
||
| def test_table_from_nested(self): | ||
| table = self.lua.table_from([[3, 3, 3]], recursive=True) | ||
|
Comment on lines
+604
to
+605
There was a problem hiding this comment. This may not have been the best example, just something that I came up with trying to understand your implementation. However, a more deeply nested example would be good, to make sure that, say, a dict of lists of dicts of dicts of lists of lists also works, or a (list) table of (mapping) tables. You're only testing one level of nesting, always starting with a dict. Maybe you can generate a data structure (or a few), map it back and forth, and then compare the result to itself? That would allow testing something larger and deeper. There was a problem hiding this comment. Accutally there are other tests which are far more deeper, for instance, the There was a problem hiding this comment. I wasn't so much referring to the depth, rather different combinations of nestings. It might make a difference whether you're mapping a list of dicts or a dict of lists. It might make a difference whether you're mapping a list of simple values or a list of lists of lists. The tests should cover different combinations. Thus, generating data structures and validating the mapping generically would be great, because it would allow quickly testing a larger range of possible structures, making sure that we're not missing edge cases, and making sure we're touching all mapping code. We're probably not covering all of it currently. There was a problem hiding this comment. Ok, I'll try to cover more tests, like There was a problem hiding this comment. What about something like this: def test():
from itertools import count
def make_ds(*children):
for child in children:
yield child
yield list(children)
yield dict(zip(count(), children))
yield {chr(ord('A') + i): child for i, child in enumerate(children)}
for ds1 in make_ds(1, 2, 'x', 'y'):
for ds2 in make_ds(ds1):
for ds in make_ds(ds1, ds2):
table = self.lua.table_from(ds)
# validate table == dsI hope it's mostly clear, the idea is to generate 0-2 level data structures of all sorts of nesting combinations, and then validate that the result looks the same in Lua as in Python. The validation would probably involve a couple of type checks and back-mappings Lua->Python, but shouldn't be too complex. The above loops generate somewhat redundant results, AFAICT, but not too bad. Maybe you can come up with something smarter even. There was a problem hiding this comment. Opps... I found a bug, and it can be reproduced in master branch, just use but There was a problem hiding this comment. The structures generated by this function should also be applied to master branch I think. There was a problem hiding this comment. By the way, there might be some gc problem with cpython itself, in the loop test there are some lua tables can't match the corresponding pyobject, but when I test them in a individual test, the problem just gone. There was a problem hiding this comment. My test code proposal was buggy. Here's a revised version that does not generate single elements: def test():
from itertools import count
def make_ds(*children):
yield list(children)
yield dict(zip(count(), children))
yield {chr(ord('A') + i): child for i, child in enumerate(children)}
elements = [1, 2, 'x', 'y']
for ds1 in make_ds(*elements):
for ds2 in make_ds(ds1):
for ds3 in make_ds(ds1, elements, ds2):
for ds in make_ds(ds1, ds2, ds3):
table = self.lua.table_from(ds)
# validate table == dsThere was a problem hiding this comment. I added this test to the master branch and merged it into this PR. Since the "validation" in the master branch is really rudimentary, it hopefully won't fail here, but can now be adapted to validate the transitive translation. |
||
| self.lua.globals()["data"] = table | ||
| self.assertLuaResult("data[1][1]", 3) | ||
| self.assertLuaResult("data[1][2]", 3) | ||
| self.assertLuaResult("data[1][3]", 3) | ||
| self.assertLuaResult("type(data)", "table") | ||
| self.assertLuaResult("type(data[1])", "table") | ||
| self.assertLuaResult("#data", 1) | ||
| self.assertLuaResult("#data[1]", 3) | ||
|
|
||
| def test_table_from_table(self): | ||
| table1 = self.lua.eval("{3, 4, foo='bar'}") | ||
|
|
@@ -632,6 +641,58 @@ def test_table_from_table_iter_indirect(self): | |
| self.assertEqual(list(table2.keys()), [1, 2, 3]) | ||
| self.assertEqual(set(table2.values()), set([1, 2, "foo"])) | ||
|
|
||
| def test_table_from_nested_dict(self): | ||
| data = {"a": {"a": "foo"}, "b": {"b": "bar"}} | ||
| table = self.lua.table_from(data, recursive=True) | ||
| self.assertEqual(table["a"]["a"], "foo") | ||
| self.assertEqual(table["b"]["b"], "bar") | ||
| self.lua.globals()["data"] = table | ||
| self.assertLuaResult("data.a.a", "foo") | ||
| self.assertLuaResult("data.b.b", "bar") | ||
| self.assertLuaResult("type(data.a)", "table") | ||
| self.assertLuaResult("type(data.b)", "table") | ||
|
|
||
| def test_table_from_nested_list(self): | ||
| data = {"a": {"a": "foo"}, "b": [1, 2, 3]} | ||
| table = self.lua.table_from(data, recursive=True) | ||
| self.assertEqual(table["a"]["a"], "foo") | ||
| self.assertEqual(table["b"][1], 1) | ||
| self.assertEqual(table["b"][2], 2) | ||
| self.assertEqual(table["b"][3], 3) | ||
| self.lua.globals()["data"] = table | ||
| self.assertLuaResult("data.a.a", "foo") | ||
| self.assertLuaResult("#data.b", 3) | ||
| self.lua.eval("assert(#data.b==3, 'failed')") | ||
| self.assertLuaResult("type(data.a)", "table") | ||
| self.assertLuaResult("type(data.b)", "table") | ||
|
|
||
| def test_table_from_nested_list_bad(self): | ||
| data = {"a": {"a": "foo"}, "b": [1, 2, 3]} | ||
| table = self.lua.table_from(data) # in this case, lua will get userdata instead of table | ||
| self.assertEqual(table["a"]["a"], "foo") | ||
| self.assertEqual(list(table["b"]), [1, 2, 3]) | ||
| self.assertEqual(table["b"][0], 1) | ||
| self.assertEqual(table["b"][1], 2) | ||
| self.assertEqual(table["b"][2], 3) | ||
| self.lua.globals()["data"] = table | ||
| self.assertLuaResult("type(data.a)", "userdata") | ||
| self.assertLuaResult("type(data.b)", "userdata") | ||
|
|
||
| def test_table_from_self_ref_obj(self): | ||
| data = {} | ||
| data["key"] = data | ||
| l = [] | ||
| l.append(l) | ||
| data["list"] = l | ||
| table = self.lua.table_from(data, recursive=True) | ||
| self.lua.globals()["data"] = table | ||
| self.assertLuaResult("type(data)", 'table') | ||
| self.assertLuaResult("type(data['key'])",'table') | ||
| self.assertLuaResult("type(data['list'])",'table') | ||
| self.assertLuaResult("data['list']==data['list'][1]", True) | ||
| self.assertLuaResult("type(data['key']['key']['key']['key'])", 'table') | ||
| self.assertLuaResult("type(data['key']['key']['key']['key']['list'])", 'table') | ||
|
|
||
| # FIXME: it segfaults | ||
| # def test_table_from_generator_calling_lua_functions(self): | ||
| # func = self.lua.eval("function (obj) return obj end") | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems unrelated. Why did you change it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this is related to another bug. If you link to your custom lua libs, the original code will fail to find corret module. Reated to this issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then please revert it. You can propose it as a separate PR, if you think that it's the right thing to do. But it's unrelated to the change in this "nested dict" PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I will put it in a seperate pr.