
On Thu, 9 Sept 2021 at 01:46, Ethan Furman <ethan@stoneleaf.us> wrote:
On 9/7/21 10:39 PM, Steven D'Aprano wrote:
On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote:
I think Nick is on board with bytes.fromint() and no bchr(), and my sense of the sentiment here is that this would be an acceptable resolution for most folks. Ethan, can you reconsider?
I haven't been completely keeping up with the entire thread, so apologies if this has already been covered. I assume that the idea is that bytes.fromint should return a single byte, equivalent to chr() returning a single character.
To me, it sounds like should be the opposite of int.from_bytes.
>>> int.from_bytes(b'Hello world', 'little') 121404708502361365413651784 >>> bytes.from_int(121404708502361365413651784, 'little') # should return b'Hello world'
That certainly makes sense to me. At this point, the only reason that would not work is an arbitrary limit of 255 on the input, and the only reason that limit is there is to have `bchr` be the inverse of `ord`. Since `bchr` isn't going to happen, I see no reason to have the 255 limit. `byteorder` can default to None with a requirement of being set when the integer is over 255.
I've posted a PR removing bchr from the proposal: https://github.com/python/peps/pull/2068/files `bytes.fromint` is still the inverse of `ord` for bytes objects, even without the `bchr` builtin alias. The spelling of the trio is just `ord`/`bytes.fromint`/`chr` rather than `ord`/`bchr`/`chr`. The fact the method throws an exception for integers that won't fit in a single byte is an input data validation feature, not an undesirable limitation. As Brandt already noted, we don't need a new general purpose int to bytes converter as `int.to_bytes` already has that covered. Cheers, Nick. P.S. The fact that it *didn't* look like the inverse operation for `int.from_bytes` was one advantage of calling the method `bytes.fromord` instead of `bytes.fromint`, but I'm still happy the SC is right that `bytes.fromint` is a more comprehensible method name overall. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia