Exception when loading DLL

[ellinorcrux]

We upgraded Python, but now we're getting a different Exception:

    self._instream = FrameInStreamSession(self._interface_name, self._database_n
ame, self._cluster_name)
  File "C:\Python27\lib\site-packages\nixnet\session.py", line 86, in __init__
    constants.CreateSessionMode.FRAME_IN_STREAM)
  File "C:\Python27\lib\site-packages\nixnet\_session\base.py", line 59, in __in
it__
    self._handle = _funcs.nx_create_session(database_name, cluster_name, list, i
nterface_name, mode)
  File "C:\Python27\lib\site-packages\nixnet\_funcs.py", line 32, in nx_create_s
ession
    ctypes.pointer(session_ref_ctypes),
  File "C:\Python27\lib\site-packages\nixnet\_cfuncs.py", line 37, in nx_create_
session
    cfunc = self.cdll.nxCreateSession
  File "C:\Python27\lib\site-packages\nixnet\_cfuncs.py", line 26, in cdll
    self._cdll = _lib.import_lib()
  File "C:\Python27\lib\site-packages\nixnet\_lib.py", line 56, in _import_win_l
ib
    cdll = ctypes.cdll.LoadLibrary(lib_name)
  File "C:\Python27\lib\ctypes\__init__.py", line 440, in LoadLibrary
    return self._dlltype(name)
  File "C:\Python27\lib\ctypes\__init__.py", line 362, in __init__
    self._handle = _dlopen(self._name, mode)
TypeError: LoadLibrary() argument 1 must be string, not unicode

• OS: Windows 7
• Python version: Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59)
• NI-XNET version: Driver version 16, nixnet (0.1.0.dev2)

[epage]

Apparently, this is a bug in Python 2.7.13 that should be fixed in 2.7.14 which should be released any day now.

It looks like DAQmx also ran into this, see ni/nidaqmx#1.

Would you prefer us to hack around this or to downgrade?

[ellinorcrux]

Well, the issue we had yesterday was because our Python version was too low, and today the issue is that Python version is too high :( I've never encountered a package that's so picky about the Python version. Having to re-install Python is a major pain point. Would prefer if you could find some way around these issues and make it work for the entire py2.7 series.

[epage]

Well, the issue we had yesterday was because our Python version was too low, and today the issue is that Python version is too high :(
...
Having to re-install Python is a major pain point. Would prefer if you could find some way around these issues and make it work for the entire py2.7 series.

Sorry for the pain this has caused and understandable. I've got an idea of what we should do and will get it implemented when I get into the office on Monday.

I've never encountered a package that's so picky about the Python version.

This is a very good point and something I've been introspecting about to ensure we have good Python2 support rather than just patching over problems.

[epage]

So onto discussing how to fix this.

Taking into account this issue and #116, my gut feel is that the root of our problem is that Python2's unicode/str support isn't mature enough for using unicode_literals. We should remove it and be explicit about unicode strings where needed.

When looking to support both versions of the language, we went gung-ho with future-imports which includes unicode_literals.

Python2 was traditionally very loose with the distinction between byte strings and text strings. They cleaned this up in Python3 but there are a lot of different cases to consider. Even worse when back porting this to Python2 where unicode types aren't native, making it harder for them to identify these problem cases. I can understand why they iterated on this so much within the Python 2.7 point releases.

In general, it seems unicode_literals is a bit a contentious within the community. For some more background on the pros and cons, I recommend python-future's notes.

[epage]

Closed by #129