Re: [zeromq-dev] Python bindings strings and bytes

2015-11-25 Thread André Caron
> From the binding perspective this would be easiest. From a user perspective it isn't If you mean that this makes it harder for the application developer using the binding because they have to figure out which encoding name to pass to .decode, then I disagree. Nothing is worse than a binding

Re: [zeromq-dev] Python bindings strings and bytes

2015-11-12 Thread Joe McIlvain
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

Re: [zeromq-dev] Python bindings strings and bytes

2015-11-11 Thread Michel Pelletier
My personal opinion is that the API should use bytes, and only bytes, and never return or accept any unicode objects. It's 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 wrote: >

[zeromq-dev] Python bindings strings and bytes

2015-11-11 Thread Arnaud Loonstra
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(b'MyZyreNode') or > zn =

Re: [zeromq-dev] Python bindings strings and bytes

2015-11-11 Thread Arnaud Loonstra
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