As you say, providing a fully idiomatic user experience is not always possible in generated bindings - this was also the case with Ruby when I was writing those bindings.
In cases where there is a conflict between idiomatic user experience and predictability, I would argue that we *must* make the generated bindings behave in a way that wraps all reasonable CLASS-style C APIs in a consistent, predictable way. As I see it, the purpose of the bindings is to wrap the entire API in such a way that the result is predictable and (to the extent possible) generally safe from SEGVs or ABRTs. Anything beyond this to provide idiomatic access is icing on the cake - we should do it if it's possible, but it is always second to predictability and safety. In cases where there is a conflict, it often requires a hand-written higher level wrapper or convenience helpers to bridge the gap. This is the best we can do, I think. On Wed, Nov 11, 2015 at 12:47 PM, Michel Pelletier < [email protected]> wrote: > > On Wed, Nov 11, 2015 at 12:29 PM, Arnaud Loonstra <[email protected]> > wrote: > >> 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. >> >> > To be fair I don't have a lot of skin in the game so take my opinion with > sufficient salt, the nice thing about bytes is that it's dirt simple. > > >> Could we embrace Python's Buffer Protocol? >> https://docs.python.org/3/c-api/buffer.html >> Also makes the exposed bytes mutable? >> > > Using buffer would be great, both bytes and bytearray implement it. I > think it can be used with mmap objects as well. +1 > > -Michel > > >> >> 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 >> > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
