[nanomsg] Re: Alpha Python bindings.

  • From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Wed, 28 Aug 2013 02:30:23 +0300

Hi Tony,

On Wed, Aug 28, 2013 at 1:50 AM, Tony Simpson <agjasimpson@xxxxxxxxx> wrote:
> 1) An interesting point, I don't know yet what is going to be required to do
> the implementation for Pypy but I think a good argument could be made that
> it would be easier to implement the translation from error codes to
> exception in one place and in python rather than in C and whatever is
> required to implement for Pypy. I understand where you are coming from
> though. I do have this strong feeling that I should stick to what the C API
> does unless its not possible in python (e.g. out parameters).
>

You may implement ctypes backend for pypy and set errcheck attribute
to raise exception. I don't familiar with other ways to write bindings
for Pypy.

> 2) I was implementing each function as I read them from the docs, by the
> time I got to nn_symbol I'd already grep'ed the symbols our of the headers
> files. I'm not sure I'm 100% convinced by the usefulness of nn_symbol at the
> moment, and I don't know how things like flake8 (python linting tool) will
> react to not having those symbols defined - I'm imagining that the
> higher-level  api will define the symbols it uses but get their values from
> nn_symbol and all the others would be merged into the module globals. I
> think I'd want to put the symbols into different namespaces but does
> nn_symbols support that, could you derive namespaces from the symbol names
> (looking at the ones that are currently defined it doesn't appear so)?
>

Well, nn_symbol doesn't support namespaces. Your current
implementation doesn't have them either. I guess for high level API
you should make a class for each socket type, and a method/property
for each socket option anyway, so that user don't need to use
constants anyway. So why bother splitting low-level constants?

AFAIK, flake8 will stop checking globals at the "from _nanomsg import
*" line, so it's irrelevant.

--
Paul

Other related posts: