Fix handling of str/bytes with ctypes; make Python 3 compatible

[llimeht]

libNeXus uses bytes for all c_char types not Python strings (unicode in Python 3). String types cannot be directly passed into libNeXus.

The encoding/decoding interface is defined as immediately next to the call into the CDLL, such that everything in Python is str type (unicode), except for data structures directly going into the C code.

Encoding/decoding is done via a specified encoding, defaulting to UTF-8.

When combined with #12, this is sufficient for the test suite to pass under Python 3.7.

[marshallmcdonnell]

Just a bump, can this be merged?
Need this as well and will be going to a fork to get a Python 3 compatibility.
Think necessary now that Python 2 is at EOL

[rayosborn]

Out of interest, are you using this to access HDF4 or XML files? I think that is the only reason this package is still maintained, because the NeXus C-API is not fully supported by the NIAC now. If you only access HDF5 files, then the separate nexusformat package is much more actively maintained.

[marshallmcdonnell]

@rayosborn Thanks for quick response!

I am using this since it is a dependency of this project: https://github.com/neutrons/shrinkeventfile
But to answer the question, yes, it is for HDF5-only.

Thanks, I did come across nexusformat but noticed it will require a re-write of shrinkeventfile.
Not a big deal, it is only hundreds of lines of code but just wanted to get this shrinkeventfile software running "as-is" first, with current python-nxs dependency (no test suite yet for shrinkeventfile)

Is there any reason to not merge these contributions, though, since still active?
Any worries about "breaking things" with these merges?

[rayosborn]

The new package is a fork of this older package, but it dropped use of the C-API in favor of h5py. Although I did originally plan to restore some way of connecting to the C-API, HDF4 support was already deprecated and new HDF5-only features were being added to NeXus, so I didn't bother. I don't think there are any capabilities in the older package that are not already available in the new one, but if you think there is some missing functionality, please let me know. I have in the past suggested removing the Python bindings to the C-API altogether to avoid confusion, but some still needed HDF4 compatibility, so the decision was postponed.