From the binding perspective this would be easiest. From a user perspective it isn't. However if we need to please the user, automatic generation of bindings gets very difficult I guess.
Could we embrace Python's Buffer Protocol? https://docs.python.org/3/c-api/buffer.html Also makes the exposed bytes mutable? We could generate less cryptic exceptions indeed. Rg, Arnaud On 2015-11-11 17:42, Michel Pelletier wrote: > My personal opinion is that the API should use bytes, and only bytes, > and never return or accept any unicode objects. > > Its a bit brutal but then at least the rules are simple. Pass > unicode, get a clear exception. > > On Wed, Nov 11, 2015 at 3:43 AM, Arnaud Loonstra <[email protected] > [3]> wrote: > >> This is a frequent issue dealing with Python but how do we want to >> deal >> with strings? Python strings are a bit cumbersome when dealing with >> C. >> >> For example to use the Zyre bindings in python one needs to do one >> of >> the following: >> >> > from zyre import Zyre >> > zn = Zyre(bMyZyreNode) >> >> or >> >> > zn = Zyre(MyZyreNode.encode(utf-8)) >> >> This will work in both major Python versions. >> The current unittest uses: >> >> > z1 = Zyre(t1) >> >> which only works in Python 2. >> >> In Python 3 this excepts: >> >> Traceback (most recent call last): >> File "test.py", line 6, in test_all >> z1 = Zyre(t1) >> File "/home/people/arnaud/src/zyre/bindings/python/zyre.py", >> line >> 129, in __init__ >> self._as_parameter_ = lib.zyre_new(args[0]) # Creation of >> new raw >> type >> ctypes.ArgumentError: argument 1: <class TypeError>: wrong type >> >> We could just use bytes for everything but it has some consequences >> and >> makes it a bit un-pythonic. For example the Zyre unittest tests for >> the >> type of a Zyre event: >> >> > self.assertEquals(e.type(), join) >> >> type() returns a Python string and not a bytes object. >> >> Actually I dont know of any other way as converting to a python >> string >> needs encoding. Anybody thoughts about this? >> >> Rg, >> >> Arnaud >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] [1] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev [2] > > > > Links: > ------ > [1] mailto:[email protected] > [2] http://lists.zeromq.org/mailman/listinfo/zeromq-dev > [3] mailto:[email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
