1

I'm trying to write a simple serialization library for some messages. I have it working and everything is good, but for some reason it keeps appending an 'L' to the end of certain messages. Literally never any other character, always an L, and always to the same pieces of data. It seems to generally stick the L on larger pieces of the data though, and I have no idea whats happening.

>>> a = messager(messager.genericHeader() + [0x1111, 0x2222, 0x33334444, 0xdeadbeefdeadbeef])
>>> b = a.serialize()
>>> b
'\xb0\xba\xfewGRYP\x00\x01\x00(\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x11\x11""33DD\xde\xad\xbe\xef\xde\xad\xbe\xef'

>>> c = a.deserialize(b)

>>> hex(c[0])
'0x1111'

>>> hex(c[1])
'0x2222'

>>> hex(c[2])
'0x33334444'

>>> hex(c[3])
'0xdeadbeefdeadbeefL'

From what I can see there are clearly no bytes on the end of the bit string that would read as an L. Does anyone have an idea about what's happening here? I could show some code too, but I'll try to keep things brief since the byte string will hopefully be enough to diagnose this issue.

1 Answers1

1

Don't worry about it,

The 'L' that gets printed shows the value is a long.

It doesnt actually do anything to the value, just how it gets represented whilst printing

muddyfish
  • 3,530
  • 30
  • 37
  • Thanks, I figured it wasn't a big deal but it threw me off. – Broccolli Rob Jul 30 '15 at 15:33
  • Note: This only happens in Python 2, and can be fixed there with: from future_builtins import hex which imports a Py3-like version of hex that won't append `L` regardless of whether you're calling it on an `int` or `long`. – ShadowRanger Jul 30 '15 at 15:38