Port to 3.5

[two7]

I tried to get this working on 3.5 and came across a few issues. I started making "fixes" but having not got any documentation to work off I'm flying blind. Does anyone have any information I can have to port this over?

Also I tried to get a string back on a 2.7 build I have but it didn't seem to work. I'd like to take this further also.

Great work so far though!

[patrickjmcd]

I believe the Python 3 issues have to do with changes to the struct library, specifically the types of returned variables.

Compare the Python 2 Documentation with the Python 3 Documentation for the struct package. You'll see that in python 2, pack returns a string, but in python 3, pack returns a bytes object. Similarly, unpack in python 2 takes a string as a parameter, but a bytes object in python 3.

I'm going to try to work on a fix for this that will work for both python 2 and python 3. @INTERCEPTOR27 How far have you gotten? It would probably be good to start this on a new branch.

[ruscito]

Actually pack and unpack should be the only problem; I don't recall other
issue when I tried to run the lib under python 3

On Fri, Nov 11, 2016 at 5:27 PM, Patrick McDonagh notifications@github.com
wrote:

I believe the Python 3 issues have to do with changes to the struct
library, specifically the types of returned variables.

Compare the Python 2 Documentation
https://docs.python.org/2/library/struct.html with the Python 3
Documentation https://docs.python.org/3/library/struct.html for the
struct package. You'll see that in python 2, pack returns a string, but in
python 3, pack returns a bytes object. Similarly, unpack in python 2 takes
a string as a parameter, but a bytes object in python 3.

I'm going to try to work on a fix for this that will work for both python
2 and python 3. @INTERCEPTOR27 https://github.com/INTERCEPTOR27 How far
have you gotten? It would probably be good to start this on a new branch.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#16 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABL5ocDfULS6aiYG68VDs-Ao71hHbIv-ks5q9PnogaJpZM4KcE3E
.

[patrickjmcd]

Yeah, I admittedly don't understand the mechanics of the request/response within CIP yet to understand it all, but it didn't seem to work when I edited the pack/unpack functions. It would only get closer to working when I used encode/decode on the results of the pack/unpack functions. I'll keep investigating on Monday

[two7]

@patrickjmcd I've got it working as far as the 2.7 version is working. I was actually talking to a colleague at work about putting the code up here as my first contribution on GitHub.

I'll tidy up the changes I've made and upload it when I'm back in the office this week. What's the best way to do it?

I would then like to take it further and get strings working as per the code previously posted.

[ruscito]

@INTERCEPTOR27 as Patrick pointed the best way will be start a new branch so that we can keep up with the two libraries. How much did you had to change?

[bpaterni]

Hi all,

A functioning(*) pycomm3 library should now be available at https://github.com/bpaterni/pycomm3

• The changes made are only the bare minimum necessary in order to get this running via python3.5. Most of it is just changing string literals/operations to their 'byte' counterparts in python3. There are likely lingering bugs on a few code paths through the library, but I thought I would publish my work so far in order to jump start migration of pycomm to python3.

Hopefully others find this useful, and if you're able, please help in making pycomm3 more complete.
:)

edit: Instead of a completely new repo (pycomm3), I forked the current ruscito/pycomm to https://github.com/bpaterni/pycomm and created a branch under it (pycomm3) to contain the changes mentioned above