[pypy-issue] [issue1309] rbigint support for from/tobytes
tracker at bugs.pypy.org
Thu Nov 1 00:33:34 CET 2012
Kenny Levinsen <kennylevinsen at gmail.com> added the comment:
The attached patch includes the following changes:
1. Define BYTEORDER in rbigint - used to determine if endianswap is needed
2. Fix frombytes, update to support endianswap. Still lacking support for signed input.
3. Implement tobytes, supporting endianswap. Lacks support for signed output.
4. Add descr_to_bytes wrapper, which carefully ignores the nbytes argument, wrap call to frombytes in try block, and properly raise ValueError on incorrect use of byteorder argument.
5. Delete _x_mul redefinition.
6. Extend rbigint unittest to test potentially problematic input, as well as endianswap
1. Handle the nbytes argument. CPython throws an OverflowError if we exceed nbytes on to_bytes().
2. Handle signed input/output. When this is done, pickling of longs in py3k will be up and running. (It can pickle/unpickle locally, but it's unaware that it's actually working with unsigned values, despite requesting
otherwise). For frombytes, this is something along the lines of:
if firstbyte: # We're dealing with the first byte
sign = -1 if c >> 7 else 1
c &= 0x7F
for tobytes, something along the lines of:
# Prior to entering the loop
accum = 1 if sign == -1 else 0
accumbits += 1
... or something like that.
3. Cleanup. This is the first time I have messed around with PyPy, and I have guessed my way to how most things work. I might be doing something really stupid somewhere, and there might be a coding convention I failed
to comply to...
Notes for cleanup:
1. I was going to conditionally define an append function - depending on byteswap . in tobytes, but while 2 identical if's look stupid, it just seemed like quite the overkill.
2. the accum |= c << accumbits results in the requirement of c being widened to the LONGTYPE, as c can end up being shifted SHIFT-1 to the left, exceding the limit of a r_uint. Using something along the lines of accum
= (accum << 8) | c would save the LONGTYPE, but I couldn't quite get 'er working that way... Heheh.
3. frombytes/tobytes take a string for little/big endian. It would probably be easier to handle that conversion up higher, while to/frombytes simply took bool or something.
PyPy bug tracker <tracker at bugs.pypy.org>
More information about the pypy-issue