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