Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LuaRuntime.table interface prevents creating table with non-string keys #31

Closed
kmike opened this issue Oct 30, 2014 · 4 comments
Closed

Comments

@kmike
Copy link
Collaborator

kmike commented Oct 30, 2014

It is not possible to create a table from {1: "foo", 20: "bar"} dict using LuaRuntime.table(**kwargs) because in Python kwarg keys must be strings.

What do you think about adding a method like .table(args, kwargs) (not sure about its name)?

@scoder
Copy link
Owner

scoder commented Oct 30, 2014

A new method .table_from(*args, **kwargs) could accept iterables and mappings (PyMapping_Check() can detect the latter). If you then want to create a Lua table from the keys of a Python dict, you could say "L.table_from(iter(dict))", i.e. pass an iterator instead of the mapping container.

I take pull requests, including documentation. :)

@kmike
Copy link
Collaborator Author

kmike commented Oct 30, 2014

Could you please clarify what should .table_from(*args, **kwargs) do when

  1. multiple arguments are passed;
  2. keyword arguments are passed?

Do you mean .table_from(obj), or do you mean something similar to dict.update, or something else?

@scoder
Copy link
Owner

scoder commented Oct 30, 2014

it would iterate over "args" and process each value separately as either mapping or iterable. Keyword arguments from "kwargs" will be added at the end as if they had been passed as a single dict. Any multiply provided keys will overwrite the previous values, so dict.update() is a good example.

@kmike
Copy link
Collaborator Author

kmike commented Oct 30, 2014

This makes sense; I'll work on a PR.

kmike added a commit to kmike/lupa that referenced this issue Nov 1, 2014
@kmike kmike closed this as completed Nov 2, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants