| msg271490 - (view) |
Author: Марк Коренберг (socketpair) * |
Date: 2016-07-28 03:32 |
| int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders. I will provide a patch. |
|
|
| msg271491 - (view) |
Author: Anilyka Barry (abarry) *  |
Date: 2016-07-28 04:12 |
| Since this is a new feature addition, this should first go through Python-ideas. However, I don't think that network-related features should go into builtin types, -1 from me. |
|
|
| msg271496 - (view) |
Author: Martin Panter (martin.panter) *  |
Date: 2016-07-28 04:50 |
| I wouldn’t mind the “host” byte order, assuming it just means use sys.byteorder. I think I have done this a few times, both when I really wanted the native byte order, and when I didn’t care, but assumed the native order might be slightly more efficient (e.g. bitwise arithmetic on 512-byte blocks). But I don’t understand the point of “net” byte order. Wouldn’t it be the same as “big”? |
|
|
| msg271497 - (view) |
Author: Berker Peksag (berker.peksag) * |
Date: 2016-07-28 04:52 |
| There is no need to go to python-ideas for this. Adding domain experts to nosy list is enough. |
|
|
| msg271501 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2016-07-28 06:03 |
| I agreed with Martin. The "host" byte order is sys.byteorder, and the "net" byteorder is just "big". There is one obvious way to specify this, and there is not need to add yet one way. Adding support of new values for byteorder would complicate and slow down the code. int.to_bytes() and int.from_bytes() already are slower then struct.pack() and struct.unpack(), and parsing the byteorder argument is the main culprit here (see also ). I'm for rejecting this idea. |
|
|
| msg271510 - (view) |
Author: Марк Коренберг (socketpair) * |
Date: 2016-07-28 08:33 |
| 1. Yes 'host' is the same as sys.buteorder 2. Yes, 'net' is the same as 'big' 3. See `struct` module: it have '!' for those who forgot which order is `network`. In most cases (i.e. some protocols or formats) 'network' order is used. 4. Support of new values will actually slightly complicate code. I will say just change, not complicte. 5. This patch will add two extra string comparings. This should not slowdown current implementation significantly. I can benchmark it. |
|
|
| msg271541 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2016-07-28 12:35 |
| -1 from me; it feels like a needless expansion of the API. |
|
|
| msg271835 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2016-08-02 18:25 |
| Марк, sorry for all this negativity. ;) But I'm also -1. What is wrong with socket.ntohs() etc.? |
|
|
| msg271836 - (view) |
Author: Марк Коренберг (socketpair) * |
Date: 2016-08-02 18:29 |
| 1. I forgot to say: since I add new items to `if.. elif...elif.....` chain after testing for 'big' and 'little', this change will not slowdown current external code. 2. Well, slowdown of to_bytes() between 'big' and 'net' on my PC give about 3 percents. 3. to_bytes(2, sys.byteorder) is timed exactly as 'host'. ./python -m timeit -s 'import sys' -n 10000000 '(1234).to_bytes(2, sys.byteorder)' # iteration counter is required to stabilize results. 4. As I think, Python should also be simple and intuitive. If everyone thinks as those, who set (-1) on this issue, we will neve add .to_bytes()/.from_bytes(), since there are already TWO (!) modules to do conversion to/from bytes: `ctypes` (https://docs.python.org/3/library/ctypes.html#ctypes.BigEndianStructure) and `struct`. Answer is: it is unsuitable and not comfort for the programmer. Why not to make really good practical API ? And also, I want to call @gvanrossum.. I'm disappointed. This change is so obvious thing, that I don't understand how to explain... |
|
|
| msg271837 - (view) |
Author: Марк Коренберг (socketpair) * |
Date: 2016-08-02 18:31 |
| @skrah, what about integers with length not equal to 2 or 4 bytes, and also signed ? |
|
|
| msg271838 - (view) |
Author: Марк Коренберг (socketpair) * |
Date: 2016-08-02 18:32 |
| Well, I provide the patch, as you can see it is very simple. |
|
|
| msg271841 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2016-08-02 18:56 |
| I'm also -1. |
|
|
| msg271842 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2016-08-02 19:13 |
| Марк, thank you for the suggestion, but we've decided to decline the request. |
|
|