python 3 support

[GoogleCodeExporter]

pylibnidaqmx doesn't support python3.  Are there any plans to do so?  I can 
assist.

Original issue reported on code.google.com by jpko...@gmail.com on 3 Jan 2014 at 11:40

[GoogleCodeExporter]

Hi,
I don't have near future plans regarding python3 support.
However, your assistance is most welcome. I can give you svn write access if 
you are interested.
Thanks,
Pearu

Original comment by pearu.peterson on 6 Jan 2014 at 9:54

[GoogleCodeExporter]

Sure, I'll take write access.  I'm a big fan of pylint, so I was going to fix 
some of the things that it complains about first.  Then I'll rewrite things in 
such a way that 2to3 can convert it automatically, and figure out how to run 
that during installation.  I can send patches for review before committing.

Original comment by jpko...@gmail.com on 6 Jan 2014 at 6:12

[GoogleCodeExporter]

Any progress on this one, jpkotta? :)

Original comment by richard.hoechenberger on 9 May 2014 at 1:34

[GoogleCodeExporter]

Sorry, I completely forgot about this.  I've just pushed the clean up stuff.  
Pylint is pretty quiet now, I have all the __future__ imports, and 2to3 
generates a pretty small diff.  There shouldn't be any user-visible changes.

I tested with a 6259 PCI DAQ on Windows.  My application, which sets analog 
outs, reads analog ins, and measures frequency, ran without issues.  

Original comment by jpko...@gmail.com on 14 May 2014 at 12:52

[GoogleCodeExporter]

I just ran pylibnidaqmx on python 3.4 on windows XP 32 bit.

Next to runnning 2to3, I had to make some little adjustments to the source. Is 
there a way to share this with you?

Original comment by qoqi.lei...@gmail.com on 9 Dec 2014 at 2:03

[GoogleCodeExporter]

Attach a patch here or email it to me.

Original comment by jpko...@gmail.com on 9 Dec 2014 at 4:39

[GoogleCodeExporter]

I had to make some minor changes to the code. The most significant change is 
the deprecation of namedtuples to customtuple. Functions in python3 are 
restricted to have less than 256 arguments. The namedtuple class does not work 
in that case.

In the patch file that I attached, are some changes I did before running 2to3. 
Afterwards, I had to change 1 extra line:
libnidaqmx.py:264:
new_args.append (bytes(a, encoding='utf-8'))

There might be a better way to circumvent this, in python 3, strings are 
unicode by default.

Furthermore, all _h_*_*.py files should be regenerated, or just deleted from 
the repository.

Original comment by qoqi.lei...@gmail.com on 15 Jan 2015 at 1:21

Attachments:

• customtuple.py
• libnidaqmx.py.patch

[pearu]

Hi @hoechenberger, @jpkotta, @fgoettfert

Fabian has kindly created a branch port_to_py3_teststage that applies above patches for Python 3 support and has some additional fixes and features. Could you guys check it out and make comments when something needs to be changed?

FYI, my general notes regarding this issue were:

1. pylibnidaqmx has to work for both Python 2 and 3, adapt the code when needed
2. keep autogenerated .py files in repo, update manually when required

To me the branch looks ok but I cannot test it at the moment. But I'd like to have the branch merged to main soon.

Best regards, Pearu

[jpkotta]

I quickly looked through the changes, and it mostly looks good. I don't have time to test right now, but I'll try to make time.

One thing that I'd change is the import winreg stuff. I'd argue that it should be an if sys.version_info.major == 3 instead of a try, then you don't need any comments and any exceptions will be actual errors. If it remains a try, at least change to except ImportError instead of catching all exceptions.

[PeterNau]

I've been using the 3.x code successfully for a while now, so I want to thank you all. It's been about a month since I downloaded, built and installed the code, but if I remember correctly, it went OK. (If there were issues, they were minor and easily overcome; sorry I don't remember, because it went quickly.) I'm using PyCharm, with Python 3.5.1, and an NI PCIe-6323 multi-function board. I've been using analog in and out and digital in and out. Next up is digital channel change detection, which uses a callback function... I'll let you know if I encounter any issues, and if anyone has suggestions, please post them.

Thanks again. -Peter

[PeterNau]

So far, it appears that callback functions don't work on this branch, either. [See update below...] The problem seems best documented in issue #7, "register_every_n_samples_event function doesn't work". I've seen no evidence that the patch in nidaq.diff supplied by valhall...@gmail.com on 24 Feb 2011 at 1:43 has been applied, so I'll have to (try to) apply it and follow the guidance in that thread -- or work around the issue some other way. BTW, in the same thread, m...@tobiasgehring.de on 29 Aug 2010 commented "I guess that the done_event and signal_event have the same problem which can be fixed the same way, but I haven't tested this."

Comments and suggestions are welcome, and I'll let you know what happens.

Thanks, -Peter

UPDATE: The callback did work once; I input a slow pulse train into a digital input line and used: self.DItask.configure_timing_change_detection( rising_edge_channel=self.channels, falling_edge_channel=self.channels ) ... def change_detect_cback(self, signalID=0, options = 0, cb_data=None):

instance method/function body...

        return 0
and
   self.DItask.register_signal_event(self.change_detect_cback,
                                    signal="change_detection",
                                    options=0, cb_data=None)

Results: the callback ran exactly once, which is good, as far as it goes, but I want it to run on every digital input edge. Otherwise, I don't understand what's going on, so I'll try to adapt and apply the nidaq.diff patch from issue #7 -- and see what happens.

[hoechenberger]

Hi @PeterNau, did you have any success? :)

[olsonse]

Hey folks,

I am in the process of moving everything in our lab to Py3--this is one of the last libraries I have to attack.

One quick question: As per @pearu's comment above, I am trying to ensure that most changes I make are compatible with both Py2 and Py3 (some of our NI systems must stay Py2 for a bit longer). I'm assuming, based on @pearu's comment above, that is the intention here also. Any experience from the folks using the Py3 branch as to how close this is?

I will do extensive testing at some near point and can contribute heavily to fixing any of the Py2/Py3 compatibility changes--just wanted to know what the current experience is.