[issue45155] Add default arguments for int.to_bytes()

Raymond Hettinger added the comment: New changeset 9510e6f3c797b4398aaf58abc1072b9db0a644f9 by Raymond Hettinger in branch 'main': bpo-45155: Apply new byteorder default values for int.to/from_bytes (GH-28465) https://github.com/python/cpython/commit/9510e6f3c797b4398aaf58abc1072b9db0a644f9

[issue45155] Add default arguments for int.to_bytes()

Change by Raymond Hettinger : -- pull_requests: +26879 pull_request: https://github.com/python/cpython/pull/28465 ___ Python tracker ___

[issue45155] Add default arguments for int.to_bytes()

Change by 4-launchpad-kalvdans-no-ip-org : -- nosy: +4-launchpad-kalvdans-no-ip-org ___ Python tracker ___ ___ Python-bugs-list

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: On Sep 16, 2021, at 00:36, STINNER Victor wrote: > > The commit title is wrong, the default "big" not sys.byteorder: > >int.to_bytes(length=1, byteorder='big', *, signed=False) >int.from_bytes(bytes, byteorder='big', *, signed=False) Oops

[issue45155] Add default arguments for int.to_bytes()

STINNER Victor added the comment: > bpo-45155 : Default arguments for int.to_bytes(length=1, > byteorder=sys.byteorder) (#28265) The commit title is wrong, the default "big" not sys.byteorder: int.to_bytes(length=1, byteorder='big', *, signed=False) int.from_bytes(bytes,

[issue45155] Add default arguments for int.to_bytes()

Change by Barry A. Warsaw : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: New changeset 07e737d002cdbf0bfee53248a652a86c9f93f02b by Barry Warsaw in branch 'main': bpo-45155 : Default arguments for int.to_bytes(length=1, byteorder=sys.byteorder) (#28265)

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: "big" by default -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: On Sep 13, 2021, at 22:12, Vedran Čačić wrote: > > > Vedran Čačić added the comment: > > I'd say yes. Of course, one way to ascertain that would be to conduct a valid > pool. ;-) People can always comment otherwise in the Discourse thread. --

[issue45155] Add default arguments for int.to_bytes()

Vedran Čačić added the comment: I'd say yes. Of course, one way to ascertain that would be to conduct a valid pool. ;-) -- ___ Python tracker ___

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: On Sep 13, 2021, at 13:39, Vedran Čačić wrote: > > The poll is invalid, since the option that most people want is deliberately > not offered. *Is* there an option that most people want? -- ___ Python tracker

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: On Sep 13, 2021, at 13:38, STINNER Victor wrote: > It seems like your proposal is mostly guided by: convert an int to a byte > (bytes string of length 1). IMO this case is special enough to justify the > usage of a different function. Like bchr() ? >

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: > I'd probably say "In the face of ambiguity, refuse the temptation to guess". > > As there's disagreement about the 'correct' default, make it None and require > either "big" or "little" if length > 1 (the default). Jelle suggested that over in Discourse,

[issue45155] Add default arguments for int.to_bytes()

Matthew Barnett added the comment: I wonder whether there should be a couple of other endianness values, namely, "native" and "network", for those cases where you want to be explicit about it. If you use "big" it's not clear whether that's because you want network endianness or because the

[issue45155] Add default arguments for int.to_bytes()

Raymond Hettinger added the comment: Just reread the thread. AFAICT not a single use case was presented for having system byte ordering as the default. However, multiple respondents have pointed out that a default to system byte ordering is a bug waiting to happen, almost ensuring that

[issue45155] Add default arguments for int.to_bytes()

Vedran Čačić added the comment: The poll is invalid, since the option that most people want is deliberately not offered. -- ___ Python tracker ___

[issue45155] Add default arguments for int.to_bytes()

STINNER Victor added the comment: > In the PEP 467 discussion, I proposed (...) Since this PEP is controversial, and this issue seems to be controversial as well, maybe this idea should be part of the PEP. -- ___ Python tracker

[issue45155] Add default arguments for int.to_bytes()

STINNER Victor added the comment: >>> (65).to_bytes() b'A' It seems like your proposal is mostly guided by: convert an int to a byte (bytes string of length 1). IMO this case is special enough to justify the usage of a different function. What if people expect int.to_bytes() always return

[issue45155] Add default arguments for int.to_bytes()

Matthew Barnett added the comment: I'd probably say "In the face of ambiguity, refuse the temptation to guess". As there's disagreement about the 'correct' default, make it None and require either "big" or "little" if length > 1 (the default). -- nosy: +mrabarnett

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: I created a Discourse poll: https://discuss.python.org/t/what-should-be-the-default-value-for-int-to-bytes-byteorder/10616 -- ___ Python tracker

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: That’s okay, Brandt’s improved sys.byteorder is fastest . % ./python.exe -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "little")' 200 loops, best of 11: 94.6 nsec per loop % ./python.exe -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "big")'

[issue45155] Add default arguments for int.to_bytes()

Petr Viktorin added the comment: > I’m not convinced. I’m more concerned with the obscurity of the API. If I > saw its use in some code I was reviewing, I’d look it up, and then I’d know > exactly what it was doing. I know you would. But there are many others who just try things until they

[issue45155] Add default arguments for int.to_bytes()

Serhiy Storchaka added the comment: Perhaps it is because "little" is checked first. One call of _PyUnicode_EqualToASCIIId() for "little" and two for "big". -- ___ Python tracker

[issue45155] Add default arguments for int.to_bytes()

Raymond Hettinger added the comment: Interestingly, "little" is faster than "big". $ python3.10 -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "little")' 500 loops, best of 11: 82.7 nsec per loop $ python3.10 -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "big")' 500 loops,

[issue45155] Add default arguments for int.to_bytes()

Serhiy Storchaka added the comment: In the stdlib, there is only one use of to_bytes() with sys.byteorder (2 in tests), 16 uses of to_bytes()/from_bytes() with 'little' (22 in tests) and 22 uses with 'big' (33 in tests). So making sys.byteorder the default will help almost nobody, and the

[issue45155] Add default arguments for int.to_bytes()

Serhiy Storchaka added the comment: The struct module has 4 different modes. By default it uses not only native byte order, but native sizes and alignments which depend on OS and compiler. You need to know all these details just to understand the format codes. I think that the struct module

[issue45155] Add default arguments for int.to_bytes()

Vedran Čačić added the comment: My sensibilities are irrelevant here. I'm just saying we already have a standard byte order for data in transit, and it was introduced long before this thing called internet (it was with capital I back then:) started to interest me. --

[issue45155] Add default arguments for int.to_bytes()

Raymond Hettinger added the comment: [Mark Dickinson] > I'd also really like to avoid a system-dependent default. [Petr Viktorin] > Exactly, a platform-dependent default is a bad idea. I concur with Petr and Mark. The principal use case for int.to_bytes is to convert an integer of

[issue45155] Add default arguments for int.to_bytes()

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: Petr Viktorin added the comment: > > Exactly, a platform-dependent default is a bad idea. A default allows using > the function without the code author & reviewer even being *aware* that there > is a choice, and that is dangerous. I’m not convinced. I’m

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: On Sep 10, 2021, at 04:06, STINNER Victor wrote: > > If the intent is to create a bytes string of length 1, I'm not sure that > "re-using" this existing API for that is a good idea. Why not? It seems an obvious and simple convenience. --

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: Just to point out, struct module also uses “native” (i.e. system) byte order by default. Any choice other than that for to_bytes() seems both arbitrary and inconsistent. > On Sep 10, 2021, at 00:48, Petr Viktorin wrote: > > Exactly, a platform-dependent

[issue45155] Add default arguments for int.to_bytes()

STINNER Victor added the comment: I dislike the idea of adding a default length to int.to_bytes(). The length changes the meaning of the output: >>> (1).to_bytes(2, 'big') b'\x00\x01' >>> (1).to_bytes(1, 'big') b'\x01' If the intent is to "magically cast an integer to a byte strings",

[issue45155] Add default arguments for int.to_bytes()

Petr Viktorin added the comment: Exactly, a platform-dependent default is a bad idea. A default allows using the function without the code author & reviewer even being *aware* that there is a choice, and that is dangerous. -- nosy: +petr.viktorin

[issue45155] Add default arguments for int.to_bytes()

Mark Dickinson added the comment: I'd also really like to avoid a system-dependent default. The danger is that code of the form some_externally_supplied_integer.to_bytes(length=4) can be written and thoroughly tested, only to fail unexpectedly some time later when that code happens to

[issue45155] Add default arguments for int.to_bytes()

Vedran Čačić added the comment: > choose one for the default so that default encoding/decoding will work cross > platform. I think "little" is the most common (intel and arm). Raymond, please don't do this. We already have a "sensible default" in a network context, and it is big endian.

[issue45155] Add default arguments for int.to_bytes()

Raymond Hettinger added the comment: Serhiy is likely thinking of other the other cases. Prior to this discussion, the principal use for to_bytes and from_bytes was for integers larger than a single byte. If we're going to add a *byteorder* default, it needs to make sense for those cases

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: For the common case where you’re using all defaults, it won’t matter. byteorder doesn’t matter when length=1. > On Sep 9, 2021, at 18:12, Raymond Hettinger wrote: > > > Raymond Hettinger added the comment: > > Perhaps instead of the system byte

[issue45155] Add default arguments for int.to_bytes()

Raymond Hettinger added the comment: Perhaps instead of the system byte ordering, choose one for the default so that default encoding/decoding will work cross platform. I think "little" is the most common (intel and arm). -- nosy: +rhettinger

[issue45155] Add default arguments for int.to_bytes()

Barry A. Warsaw added the comment: > Ah, signed=False by default, so (128).to_bytes() will work. But I still worry > that it can provoke writing more errorprone code. Can you elaborate on that? Obviously no existing code will change behavior. I really don’t expect people to write

[issue45155] Add default arguments for int.to_bytes()

Serhiy Storchaka added the comment: Ah, signed=False by default, so (128).to_bytes() will work. But I still worry that it can provoke writing more errorprone code. -- ___ Python tracker

[issue45155] Add default arguments for int.to_bytes()

Serhiy Storchaka added the comment: So (128).to_bytes() will raise an error, right? I afraid also that it will lead to some programs working correctly only on platforms with the most common byte order, just because authors are not aware of byte ordering. Currently the interface forces

[issue45155] Add default arguments for int.to_bytes()

Nick Coghlan added the comment: Never mind, I've forced network byte order in struct strings for so long I had forgotten that native byte order was also the default there. Hence I withdraw that objection. -- ___ Python tracker

[issue45155] Add default arguments for int.to_bytes()

Nick Coghlan added the comment: Rather than defaulting to sys.byteorder, could the byte order default to None and only be optional when not needed? (input value fits in a single byte, output is a single byte) Otherwise the difference in defaults between this method and the struct module

[issue45155] Add default arguments for int.to_bytes()

Change by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45155] Add default arguments for int.to_bytes()

Change by Barry A. Warsaw : -- keywords: +patch pull_requests: +26685 pull_request: https://github.com/python/cpython/pull/28265 ___ Python tracker ___

[issue45155] Add default arguments for int.to_bytes()

New submission from Barry A. Warsaw : In the PEP 467 discussion, I proposed being able to use >>> (65).to_bytes() b'A' IOW, adding default arguments for the `length` and `byteorder` arguments to `int.to_bytes()`