-
Notifications
You must be signed in to change notification settings - Fork 21
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
Comments
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. |
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. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
asvalue_t
, but it seems like you could store aPyObject *
by simply casting it tovalue_t
.The text was updated successfully, but these errors were encountered: