> Are we still aiming for some sort of consistency between the different OO > scripting language bindings or not? If we are, then we should probably > coordinate things between Python, Ruby and Java so that they don't diverge > where practical.
Great question. As I have developed the new Python bindings I have thought about this. Some areas that came up: * For an OO language, it is awkward to instantiate a Socket by hand when you have to pass the Context: s = Socket(ctx, zmq.REP) A better approach would be to let the context create the Socket: ctx.create_socket(zmq.REP) That way, you are sure to get the ctx argument correct. This is implemented in the Python binding. * It is tempting to make the different socket types subclasses: SocketBase RepSocket ReqSocket P2PSocket Rather than using the zmq.REP|REQ... flags. I did not implement this as it seemed to go too afar from the C/C++ bindings. * I need the ability to bind a Socket to a random port number (0). Because ZMQ doesn't support this, I implemented a bind_to_random_port method that tries random ports in a range until it finds one and then returns that port number. http://github.com/ellisonbg/pyzmq/blob/master/zmq/_zmq.pyx#L287 * My interface to poll in modeled on Python's built-in select.poll module: It has a Poller class which you create and then call register to add fds/sockets: p = Poller() p.register(s1) p.register(s2) p.poll(timeout=10) p.unregister(s1) * I have added additional methods to the Socket object to serialize Python objects and send messages in various formats: send_json, recv_json (json) and send_pyobj, recv_pyobj (pickle). Overall, the core API of the Python bindings follows the C/C++ very closely though. I am willing to change some of the core API of the Python bindings if needed but I do think it is important for each language to create an API that follows the spirit of the language. Cheers, Brian > (Obviously if a language binding does something in a way specific to > language X then so be it. But the overall model should be the same > otherwise they're no longer bindings to the 0MQ API but separate APIs which > will hurt adoption.) > > -mato > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
