[zeromq-dev] patch for libpyzmq

[Martin Sustrik]

Hi Erich,

>     We've decider to add a new function not to break backward
>     compatibility. Thus there's still receive fucntion working as it
>     used to as well as receive2 function that works the way you've
>     designed it.
> 
> 
> Cool.  I think a different name might be more "pythonic"[1] tho, 
> something like receive_full or receive_queue.

Feel free to suggest one. In any case we'll have to break backward 
compatibility at some point in the future to clean up the API (we want 
to do that _once_ rather than introducing small changes to API in each 
release) - at that point receive and receive2 will be merged into single 
"receive" function.

>     Btw, before receive2 is stabilised, you may consider enhancing it by
>     an option to do non-blocking message reception. All you have to do
>     is to call C++ receive with 'block' parameter set to false and
>     return (0, empty-message) pair in case no message was received.
> 
>  
> I will look into this in the very near future. For this project what do 
> you mean by "stabilized"?

In this context I've meant that the version with release2 was not yet 
released and so you can tweak the function in any way you want without 
breaking backward compatibility.

> Somewhat related to all of this:
> I've been looking into using the Boost.Python library (available under a 
> MIT like license) for wrapping up the 0mq code.  From what I know of 
> that library so far, it will allow for a "more pythonic" translation to 
> python.  This may not be a direct, 1:1 mapping of methods and objects, 
> but something close which also utilizes certain python idioms.  My 
> question here is, would this be something you guys would want official, 
> or a separate but related project?

Both ways are OK. "Official" project would require a bit more caution 
about licences and more QA from our side, the upside would be that we 
would be able to ship the project with the rest of 0MQ in a single 
package, do shared marketing etc. If the project wins recognition of the 
Python community we can even use it to replace current python extension 
to 0MQ.

With separate project you would have to take care of updating it and 
releasing it yourself. The upside would be more freedom about licenses.

I would personally prefer the former, however, the decision is up to you.

Cheers.
Martin