classification
Title: int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.6
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: abarry, berker.peksag, gvanrossum, mark.dickinson, martin.panter, rhettinger, serhiy.storchaka, skrah, socketpair
Priority: normal Keywords: patch

Created on 2016-07-28 03:32 by socketpair, last changed 2016-08-02 19:13 by rhettinger. This issue is now closed.

Files
File name Uploaded Description Edit
host_net.patch socketpair, 2016-08-02 18:03 Patch for the task review
Messages (13)
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) * (Python triager) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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 issue27574).

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) * (Python committer) Date: 2016-07-28 12:35
-1 from me; it feels like a needless expansion of the API.
msg271835 - (view) Author: Stefan Krah (skrah) * (Python committer) 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) * (Python committer) Date: 2016-08-02 18:56
I'm also -1.
msg271842 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-08-02 19:13
Марк, thank you for the suggestion, but we've decided to decline the request.
History
Date User Action Args
2016-08-02 19:13:30rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg271842

resolution: rejected
2016-08-02 18:56:21gvanrossumsetmessages: + msg271841
2016-08-02 18:33:56socketpairsetnosy: + gvanrossum
2016-08-02 18:32:41socketpairsetmessages: + msg271838
2016-08-02 18:31:54socketpairsetmessages: + msg271837
2016-08-02 18:29:27socketpairsetmessages: + msg271836
2016-08-02 18:25:52skrahsetnosy: + skrah
messages: + msg271835
2016-08-02 18:03:29socketpairsetfiles: + host_net.patch
keywords: + patch
2016-07-28 12:35:18mark.dickinsonsetmessages: + msg271541
2016-07-28 08:33:49socketpairsetmessages: + msg271510
2016-07-28 06:03:36serhiy.storchakasetmessages: + msg271501
2016-07-28 04:52:39berker.peksagsetnosy: + berker.peksag, serhiy.storchaka, mark.dickinson
messages: + msg271497
2016-07-28 04:50:39martin.pantersetnosy: + martin.panter
messages: + msg271496
2016-07-28 04:12:56abarrysetnosy: + abarry
messages: + msg271491
2016-07-28 03:32:51socketpairsettype: enhancement
components: + Library (Lib)
versions: + Python 3.6
2016-07-28 03:32:33socketpaircreate