Added the ability (and tests of) integer, float, tuple, and frozenset keys

[Jwink3101]

closes #73

[menshikh-iv]

Thanks for the PR, I have 2 main questions:

• How this change affects to performance (memory usage, speed)?
• What's about other types (that didn't mentioned here)?

[Jwink3101]

Performance should be trivially affected. For string/bytes keys (all that currently work) the only overhead is a few conditionals. For the new key types, there is the slight overhead of json but that is only incurred for the new key types and again is very small and likely not even measurable compared to other aspects of the code.

As for other types, I do not have a good answer. While there are a few exceptions, any hashable python object can be a key but would require manual implementation to handle them. One option would be to instead pickle the object and compare the keys that way. I think this introduces even more overhead. Also, should the user wish to look at the sqlite file elsewhere, the keys would be imperceptible (In my use of sqlitedict, I use a modified json encoder with pickle fallback so the dict remains human readable). Still, this may be a valid approach. update: a quick test shows this pickle-based approach may falter. While the resulting object between say (u'a',u'b') on python 2 and 3 pass equality checks, the pickled form, including base64 encoding too, is not equal. None of this changes whether this approach is good for the mentioned types of objects (I still think it is) but it precludes reliably using pickles as keys /update

I will address a few more issues in the discussion of #73

[mpenkov]

Please run your code through flake8 so that it conforms to the PEP8 standard. e.g. 2 line spacing after functions, no lines with only whitespace, etc.

Next, while I think your new behavior is useful, it introduces the risk of backward compatibility and performance issues. So, I think this behavior should be disabled by default. Add two keyword parameters to the constructor:

• serialize: convert an arbitary object to a string
• deserialize: convert an arbitrary string to an object

where deserialize(serialize(obj)) == obj

By default, both of them should be None, in which case, the old behavior is used. If the user specifies only one of them, raise ValueError. If the user specifies both of them, then we can use them instead of your current convertkey/unconvertkey functions.

This approach has several benefits:

1. Maintains existing behavior (compatibility, efficiency)
2. Addresses the problem in the original issue
3. Extensible: people can use their own serialization functions if the built-in ones are insufficient

[mpenkov]

Please use a more helpful function name, like serialize (and conversely, deserialize).

[mpenkov]

Ping @Jwink3101 are you able to finish this PR?

[jayvdb]

It would be very helpful to allow passing in a JSONEncoder to be used here as a cls=.. argument, to allow inclusion of types which need help serialising.

This could be done after your PR, if you like, but that may be a useful element in the design of this PR.

[jayvdb]

this should have assertions about the underlying generated key names, possibly as separate test method, but also here so it is possible to understand the implementation by reading the tests

[jungerm2]

This might be part of a more significant issue, a user treating an SqliteDict as a normal dictionary will expect it to work like a normal python dictionary: any hashable object should be able to be used as a key, and will not be mutated as it's added to the dict.

Currently, keys are mutated:

In [1]: from sqlitedict import SqliteDict

In [2]: db = SqliteDict("/nobackup/tmp/db1.sqlite")

In [3]: key, value = 1, 1

In [4]: db[key] = value

In [5]: list(db.keys())
Out[5]: ['1']

In [6]: list(db.values())
Out[6]: [1]

This seems to occur because the default encode_key is the identity but sqlite turns it into a string. Why isn't the pickle/base64 based encode/decode_key the default?

[Jwink3101]

The problem with using python’s hash or pickle is that they are not cross platform or cross versions. It’s a tough problem!

My code is one option but another is just education.