[zeromq-dev] Fwd: Re: New Python bindings

Martin Sustrik sustrik at 250bpm.com
Mon Feb 15 19:04:32 CET 2010

>> As for the API, my suggestion would be to allow changing the behavior using
>> a socket option rather than changing the signature of the send function.
>> That way people don't have to care about the issue unless they have extreme
>> latency requirements.
> I think it would be nice though to have the option to use the two
> version on a per send basis.
> Maybe most of the send an app will do are small and should use the
> copy version, but a few could
> be really big where it makes a difference.  Plus, the new sig will not
> require the user to know about
> the options:
> def send(msg, flags=0, copy=True)
> But if you think that API compat. in send is important I can make it
> an option to the Socket constructor or
> setsockopt.

Tachnically, there's not much difference. It's more of philosophical 
issue. Say 0MQ C API as well as BSD socket API is pretty neat because 
the developers haven't changed the signatures because every little 
performance tweak in the implementation. If you fail to do so, you'll 
end up with functions with many obscure and hard-to-grasp parameters and 
the learning curve of the product as a whole will be much steeper.

Handling performance tweaks via socket options is nice because it allows 
99% of users to simply ignore it. Professionals can still use them though.


More information about the zeromq-dev mailing list