[issue1023290] Conversion of longs to bytes and vice-versa.
Mark Dickinson dicki...@gmail.com added the comment: Closing this; it's too late for Python 2.7. -- status: open - closed versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Mark Dickinson dicki...@gmail.com added the comment: The backport wasn't as straightforward as I'd hoped, and we've pretty much run out of time for 2.7. One issue is that long.from_bytes(b, ...) converts b to bytes type using the equivalent of bytes(b). This doesn't work well in 2.7 (consider bytes([255, 0, 0]) for example. So different code is needed in 2.7 when interpreting an arbitrary Python object as a sequence of bytes. Perhaps the 2.7 version could just iterate over the given object, and raise an exception if any of the iterates are not integers in the range [0, 256). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Mark Dickinson dicki...@gmail.com added the comment: A couple of questions for the backport: (1) should the 'signed' parameter remain keyword-only in 2.7? I'd say yes, to avoid issues when forward-porting code from 2.7 to 3.2. On the other hand, 2.7 doesn't support keyword-only arguments at the Python level, so a keyword-only argument might be a bit of a surprise to users. (2) When specifying the byteorder, is there a need to allow u'big' and u'little' as well as 'big' and 'little'? -- priority: low - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Alexandre Vassalotti alexan...@peadrop.com added the comment: Mark Dickinson added the comment: (1) should the 'signed' parameter remain keyword-only in 2.7? We should keep it as a keyword-only argument. Also, issue #1745 might bring keyword-only arguments to 2.7. (2) When specifying the byteorder, is there a need to allow u'big' and u'little' as well as 'big' and 'little'? Allow both. Since, 'big' == u'big' is True, it would be weird to treat them differently in this case. Plus, it will make life easier for people who uses: from __future__ import unicode_literals in their code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Mark Dickinson dicki...@gmail.com added the comment: Thanks, Alexandre! Agreed on both points. I don't really want to allow u'big' and u'little', but I think that's just my laziness talking. (Apart from that, I have a working patch.) There's some precedent for not allowing the unicode versions: float.__getformat__(double) 'IEEE, little-endian' float.__getformat__(udouble) Traceback (most recent call last): File stdin, line 1, in module TypeError: __getformat__() argument must be string, not unicode But I admit it isn't particularly compelling. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Mark Dickinson dicki...@gmail.com added the comment: I'd still like to see this backported to 2.7; if no-one else is interested in doing the backport, I'll try to find time before the betas. (Alexandre, if you want to do the backport, please do steal the issue from me.) -- assignee: alexandre.vassalotti - mark.dickinson status: closed - open versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Changes by Brian Curtin cur...@acm.org: -- nosy: +brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Alexandre Vassalotti alexan...@peadrop.com added the comment: Committed in r77394. Thank you for the good reviews! -- resolution: - accepted stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Mark Dickinson dicki...@gmail.com added the comment: Looks good to me, too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Mark Dickinson dicki...@gmail.com added the comment: All tests pass on OS X 10.5/Intel, except that I'm still getting the issue 6687 test failure. This needs to be resolved somehow before committing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Antoine Pitrou pit...@free.fr added the comment: The following example is strange: + int.from_bytes([255, 0, 0], byteorder='big') +-65536 Isn't `signed` supposed to be False by default? The rest looks ok. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Alexandre Vassalotti alexan...@peadrop.com added the comment: Here's an updated patch. - Renamed tobytes() to to_bytes() and frombytes() to from_bytes(). - Moved the changes to pickle to a different patch. - Made the NULL-checks more consistent with the rest of long's code. - Fixed the type check of the `length' parameter of to_bytes() to use PyIndex_Check() instead of PyLong_Check(). -- dependencies: +Move the special-case for integer objects out of PyBytes_FromObject. Added file: http://bugs.python.org/file15333/long_and_bytes_conversion-3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Mark Dickinson dicki...@gmail.com added the comment: The patch looks great! Some comments: - I think the type check for length_obj in long_tobytes should be more lenient: I'd suggest a PyIndex_Check and PyNumber_AsSsize_t conversion instead of the PyLong_Check. Or just use 'n' instead of 'O' in the PyArg_Parse* format; this uses PyNumber_Index + PyLong_AsSsize_t, which amounts to the same thing (or at least I *think* it does). - I like the pickle changes, but I think they should be committed separately. (Unless they're somehow required for the rest of the patch to function correctly?) - Stylistic nit: There's some inconsistency in the NULL checks in the patch: if (args != NULL) versus if (is_signed_obj). PEP 7 doesn't say anything about this, but the prevailing style in this file is for an explicit '== NULL' or '!= NULL'. - I'm getting one failing test: test.support.TestFailed: Traceback (most recent call last): File Lib/test/test_long.py, line 1285, in test_frombytes self.assertRaises(TypeError, int.frombytes, , 'big') AssertionError: TypeError not raised by frombytes This obviously has to do with issue 6687; as mentioned in that issue, I'm not sure that this should be an error. How about just removing this test for now, pending a decision on that issue? - Nice docs (and docstrings)! On the subject of backporting to 2.7, I haven't seen any objections, so I'd say we should go for it. (One argument for not backporting new features is to provide incentive for people to upgrade, but I can't realistically see this addition as a significant 'carrot'.) I'm happy to do the backport, and equally happy to leave it to Alexandre if he's interested. Leaving the bikeshedding until last: Method names: I'm +0 on adding the extra underscore. Python's already a bit inconsistent (e.g., float.fromhex and float.hex). Also, at the time the float.fromhex and float.hex names were being discussed, 'hex' seemed to be preferred over 'tohex'; I wonder whether we should have int.bytes instead of int.to_bytes? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Alexandre Vassalotti alexan...@peadrop.com added the comment: Here's a new patch incorporating the suggestions I received on python-ideas. Notable changes are: - The name of the methods have been changed to int.tobytes() and int.frombytes(). - The tri-state `little_endian' argument has been removed in favor of the `byteorder' argument which takes either the string 'little' or 'big'. - The `byteorder' argument has to be specified explicitly. - The variable-length version of int.tobytes() has been removed. - The `fixed_length' argument has been renamed to `length'. - The `signed' argument is now keyword-only and now defaults to False. -- assignee: - alexandre.vassalotti components: +Interpreter Core stage: - patch review title: proposed struct module format code addition - Conversion of longs to bytes and vice-versa. versions: +Python 3.2 Added file: http://bugs.python.org/file14739/long_and_bytes_conversion-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Martin v. Löwis mar...@v.loewis.de added the comment: Before this gets applied, a (preferably final) decision should be made whether it should be provided for 2.7 as well. Personally, it would be fine with me either way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1023290] Conversion of longs to bytes and vice-versa.
Antoine Pitrou pit...@free.fr added the comment: Alexandre: Notable changes are: - The name of the methods have been changed to int.tobytes() and int.frombytes(). Without wanting to bikeshed, I think these methods should take underscores as other int methods already do. This kind of inconsistencies is really annoying (have you ever used PHP? :-)). Martin: Before this gets applied, a (preferably final) decision should be made whether it should be provided for 2.7 as well. Personally, it would be fine with me either way. I'm also fine with adding it to 2.7 as well. But someone has to provide a patch (2.7 still has both `int` and `long`, which will make the task a bit more involved than a straight backport). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1023290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
