P.S. perhaps we should be using:
locale.getpreferredencoding()
to determine the default path and tag encoding? Opinions, Experiences,...?
Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
On Thu, 15 Sep 2011 13:41:11 -0400, Martin Owens wrote:
> I've attached a diff for some proposed changes to help make dealing with
> unicode and strings in the bindings more regular. I noticed some of the
> methods were protected and others were not.
I've now pushed a slightly modified version of
On Thu, 15 Sep 2011 13:41:11 -0400, Martin Owens wrote:
I've attached a diff for some proposed changes to help make dealing with
unicode and strings in the bindings more regular. I noticed some of the
methods were protected and others were not.
I've now pushed a slightly modified version of
This seems like a symptom of a much bigger problem. Shouldn't the
bindings be checking or coercing the type of *every* argument that
gets passed from the caller through to a ctypes-wrapped libnotmuch
function? Otherwise, a simple type error in a caller, like passing a
number instead of a string
Hello Sebastian,
I've attached a diff for some proposed changes to help make dealing with
unicode and strings in the bindings more regular. I noticed some of the
methods were protected and others were not.
Let me know.
Best Regards, Martin Owens
On Thu, 2011-09-08 at 15:45 +0200, Sebastian
Hello Sebastian,
I've attached a diff for some proposed changes to help make dealing with
unicode and strings in the bindings more regular. I noticed some of the
methods were protected and others were not.
Let me know.
Best Regards, Martin Owens
On Thu, 2011-09-08 at 15:45 +0200, Sebastian
This seems like a symptom of a much bigger problem. Shouldn't the
bindings be checking or coercing the type of *every* argument that
gets passed from the caller through to a ctypes-wrapped libnotmuch
function? Otherwise, a simple type error in a caller, like passing a
number instead of a string
