Broken on Python3 about unqlite-python HOT 5 CLOSED

No plans for py3k at the moment. I'll update the docs.

from unqlite-python.

Thanks! Good thing I keep Python 2 around. :)

from unqlite-python.

Check out #16 for a pull-request that has py3k compatibility changes. Not sure yet if I'll merge it due to performance considerations, but if it proves to be just as fast, then I will probably go ahead and merge.

from unqlite-python.

You can always just use that guys' branch, though.

from unqlite-python.

I'm the guy with the Py 3 branch.

The problem with Python 3 is that its native strings are Unicode. UnQLite however deals only with byte strings, it does not have any concept of encoding.

So to faciliate usage in Python 3 and (also in Python 2 if you're using Unicode which you should), I decided to transparently encode/decode data on ingress/egress (using utf-8 encoding) and use the same interface for both, in a backward compatible way.

Because of this there is always an overhead of a type check.

I'm not really sure about the automatic conversion on egress. Currently I do this in Python 3, but not in Python 2. So you always get the native strings back.

If you have better ideas of dealing with the Unicode issue, let me know. Of course we could simply provide different methods or classes for bytestring and unicode, but that would be an ugly duplication of the interface and error prone for users, because they might end up calling the wrong methods.

from unqlite-python.