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

Is there any particular reason you don't allow storing arbitrary Python objects as values? #7

Closed
b4hand opened this issue May 16, 2014 · 3 comments · Fixed by #8
Closed

Comments

@b4hand
Copy link
Contributor

b4hand commented May 16, 2014

I was curious if there was any particular reason you don't allow storing arbitrary Python objects as values?

It looks like the underlying C library just stores unsigned long as value_t, but it seems like you could store a PyObject * by simply casting it to value_t.

@kmike
Copy link
Member

kmike commented May 16, 2014

I think that's a good idea.

It seems it is better to still support "raw" int values (maybe in a base class) because this is more memory efficient when the values are ints.

@b4hand
Copy link
Contributor Author

b4hand commented May 16, 2014

Yeah, I figured I'd rename the current Trie class to IntTrie or something similar and then add a new Trie class that allows arbitrary value storage.

@kmike
Copy link
Member

kmike commented May 16, 2014

That would be perfect.

b4hand added a commit to b4hand/hat-trie that referenced this issue May 19, 2014
b4hand added a commit to b4hand/hat-trie that referenced this issue May 20, 2014
@kmike kmike closed this as completed in #8 May 21, 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

Successfully merging a pull request may close this issue.

2 participants