Mailing List Archive

> On 8 Sep 2021, at 06:39, Steven D'Aprano <steve@pearwood.info> 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'

:>>> int.from_bytes(b'\x00\x00\x00\x01', byteorder='big')
1
:>>> bytes.from_int(1)
would return b'\x01'? Without a length it cannot return b'\x00\x00\x00\x01'

Barry

Steven D'Aprano wrote:
> 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'
> If that's not the API being suggested, that's going to be confusing.

I'm a bit lost here... why are we convinced at all that we need a new way to do this? Hasn't this functionality already existed for years?

>>> x = int.from_bytes(b"*", "little")
>>> x
42
>>> x.to_bytes(1, "little")
b'*'

Brandt
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FMG5K4BOX5GSUR2KU3G5ZLBBUIC3EQKD/
Code of Conduct: http://python.org/psf/codeofconduct/

What am I missing?

The integers between 0 and 255 map directly to a particular byte value.

But any other integer could be expressed as a wide variety of multiple byte
combinations.

The proposal here covers byte-order, but what about 16 vs 32 vs 64 bits?
Unsigned vs signed?

I thought that’s what the struct module is for.

There is the byte representation of Python’s bignum, but is that consistent
across platforms and implementations?
(Micropytjon, PyPy, IronPython, Jython)

And even if so, is it useful?

NOTE: my objection to “bchr”, whether as a builtin or not is not the
functionality, it’s the name. Equating a byte with a character is a legacy
of C ( and Python 2” — in Python 3, they are completely distinct concepts.
Yes, that is serious bike-shedding :-)

-CHB



On Wed, Sep 8, 2021 at 10:16 AM Barry Scott <barry@barrys-emacs.org> wrote:

>
> On 8 Sep 2021, at 06:39, Steven D'Aprano <steve@pearwood.info> 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'
>
>
> :>>> int.from_bytes(b'\x00\x00\x00\x01', byteorder='big')
> 1
> :>>> bytes.from_int(1)
> would return b'\x01'? Without a length it cannot return
> b'\x00\x00\x00\x01'
>
> Barry
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TTFJ4VP5PCR557VHEH5LPSWAPNPE4QQU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

On 9/8/21 1:21 PM, Christopher Barker wrote:

> NOTE: my objection to “bchr”, whether as a builtin or not is not the functionality, it’s the
> name. Equating a byte with a character is a legacy of C ( and Python 2” — in Python 3, they
> are completely distinct concepts.

No, they aren't. If you are working in a domain that uses ascii encoding (such as many network protocols), then those
bytes represent characters -- this is why, for example, %-interpolation was added back to bytes.

--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4BG2BXAE3RGKQEGBHYW4IRLHEB3G6XNR/
Code of Conduct: http://python.org/psf/codeofconduct/

On 08/09/2021 21:21, Christopher Barker wrote:
>
> [snip]
> NOTE: my objection to “bchr”, whether as a builtin or not is not the
> functionality, it’s the name.

> [snip]
Why not byte() ?

I happened to need to convert an integer to a byte recently and I settled on
    bytes((i,))
I don't know if I missed a more elegant solution (suggestions welcome),
but if I could write
    byte(i)
that would feel more Pythonic to me.
Best wishes
Rob Cliffe
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YTR5XL5FR66KLXRVATZIZPNXPZRP7CLU/
Code of Conduct: http://python.org/psf/codeofconduct/

On 2021-09-09 00:29, Rob Cliffe via Python-Dev wrote:
>
>
> On 08/09/2021 21:21, Christopher Barker wrote:
>>
>> [snip]
>> NOTE: my objection to “bchr”, whether as a builtin or not is not the
>> functionality, it’s the name.
>
>> [snip]
> Why not byte() ?
>
> I happened to need to convert an integer to a byte recently and I settled on
>     bytes((i,))
> I don't know if I missed a more elegant solution (suggestions welcome),
> but if I could write
>     byte(i)
> that would feel more Pythonic to me.
>
Well, I tend to see a byte as a value like an int.

If you slice a bytestring, you'd expect to get a bytestring, and you do.

If you subscript a bytestring, you expect to get a byte. You get an int,
and that suggests that a byte is an int. (In Python 2 you got a
bytestring, in Python 3 you get an int.)

The name could be misleading as byte(i) would return a bytestring, not a
byte/int.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UU2QW6KV36H5RRFL6UG2REOFRWWXKCUK/
Code of Conduct: http://python.org/psf/codeofconduct/

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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2QO35ROTATWQWR6DMHY5BOS25QK2YLER/
Code of Conduct: http://python.org/psf/codeofconduct/

Hum, it seems like this is a confusion between converting a whole
bytes *string* to/from an integer, and converting a single *character*
to/from an integer.

I propose to rename PEP 467 method bytes.fromint(n) to =>
bytes.fromchar(n) <= to convert an integer to a single *character*: it
fails if n is not in the [0; 255] range. "char" comes from
"character", as "bchr()" means "bytes character".

For C programmers, the usage of the "char" type is common for a single
*character*. The char type is not treated as an integer, but part of a
character string. All string functions take "char*" type (strcpy,
printf, etc.). Converting an integer to a "char" in C: "int x = 1;
char ch = (char)x;".

I suggest to *not* add a builtin function bchr(), it's not common
enough to justify to add it: it's trivial to create you own bchr()
function:

bchr = bytes.fromchar

By the way, it's a little unfortunate that int methods have an
underscore in their name (int.to_bytes, int.bit_length,
int.as_integer_ratio), whereas bytes methods have no undersore in
their name (bytes.removeprefix, bytes.islower). I guess that we should
follow the trend of existing methods: so no underscore for
bytes/bytearray methods.

Victor

On Wed, Sep 8, 2021 at 7:06 PM Brandt Bucher <brandtbucher@gmail.com> wrote:
>
> Steven D'Aprano wrote:
> > 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'
> > If that's not the API being suggested, that's going to be confusing.
>
> I'm a bit lost here... why are we convinced at all that we need a new way to do this? Hasn't this functionality already existed for years?
>
> >>> x = int.from_bytes(b"*", "little")
> >>> x
> 42
> >>> x.to_bytes(1, "little")
> b'*'
>
> Brandt
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FMG5K4BOX5GSUR2KU3G5ZLBBUIC3EQKD/
> Code of Conduct: http://python.org/psf/codeofconduct/



--
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TGUWZ7FV7CA5LOCPIFOP3WUP6Z5NQDTD/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, 9 Sep 2021 18:55:04 +1000
Nick Coghlan <ncoghlan@gmail.com> wrote:
>
> 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.

Perhaps we can call it `bytes.byte` to make it unambiguous?

Regards

Antoine.


_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WZUPBP4UASRCJLAKP6FMQJLLMYJY22CL/
Code of Conduct: http://python.org/psf/codeofconduct/

I proposed bytes.byte earlier in this thread:
https://mail.python.org/archives/list/python-dev@python.org/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/

Gregory dislikes the name: "I don't *like* to argue over names (the
last stage of anything) but I do need to point out how that sounds to
read".
https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/

That's why I proposed: bytes.fromchar(). I still like bytes.byte() :-)

Victor

On Thu, Sep 9, 2021 at 11:07 AM Antoine Pitrou <antoine@python.org> wrote:
>
> On Thu, 9 Sep 2021 18:55:04 +1000
> Nick Coghlan <ncoghlan@gmail.com> wrote:
> >
> > 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.
>
> Perhaps we can call it `bytes.byte` to make it unambiguous?
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WZUPBP4UASRCJLAKP6FMQJLLMYJY22CL/
> Code of Conduct: http://python.org/psf/codeofconduct/



--
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6W4G32NOBXAQ73VESVE4UL7AZIWUAD6A/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, 9 Sep 2021 12:06:49 +0200
Victor Stinner <vstinner@python.org> wrote:
> I proposed bytes.byte earlier in this thread:
> https://mail.python.org/archives/list/python-dev@python.org/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/
>
> Gregory dislikes the name: "I don't *like* to argue over names (the
> last stage of anything) but I do need to point out how that sounds to
> read".
> https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/
>
> That's why I proposed: bytes.fromchar(). I still like bytes.byte() :-)

Well, the proposed function converts *from* an integer *to* a byte
"character". But the term character is a bit unfortunate here as well,
since characters in Python are Unicode.

Regards

Antoine.


_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BXUPHBDTEGSBZGEXYDUERLGL5BTYB5DY/
Code of Conduct: http://python.org/psf/codeofconduct/

It probably won't fly but why not bytes.frombyte?

There's no such thing as a byte type in Python, only bytes, so I want
to argue it makes it clear the argument is a number in the range
0..255 and the result is a bytes object containing this single byte
value.

Tentatively,

Arnaud

PS. But truly I feel like this method is superfluous.

On Thu, 9 Sept 2021 at 11:11, Victor Stinner <vstinner@python.org> wrote:
>
> I proposed bytes.byte earlier in this thread:
> https://mail.python.org/archives/list/python-dev@python.org/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/
>
> Gregory dislikes the name: "I don't *like* to argue over names (the
> last stage of anything) but I do need to point out how that sounds to
> read".
> https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/
>
> That's why I proposed: bytes.fromchar(). I still like bytes.byte() :-)
>
> Victor
>
> On Thu, Sep 9, 2021 at 11:07 AM Antoine Pitrou <antoine@python.org> wrote:
> >
> > On Thu, 9 Sep 2021 18:55:04 +1000
> > Nick Coghlan <ncoghlan@gmail.com> wrote:
> > >
> > > 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.
> >
> > Perhaps we can call it `bytes.byte` to make it unambiguous?
> >
> > Regards
> >
> > Antoine.
> >
> >
> > _______________________________________________
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-leave@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WZUPBP4UASRCJLAKP6FMQJLLMYJY22CL/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6W4G32NOBXAQ73VESVE4UL7AZIWUAD6A/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/P7XG5CLLBXZTS6UE72KSGWLVYXRDXKT4/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, Sep 09, 2021 at 10:57:26AM +0200, Victor Stinner wrote:

> I propose to rename PEP 467 method bytes.fromint(n) to =>
> bytes.fromchar(n) <= to convert an integer to a single *character*: it
> fails if n is not in the [0; 255] range. "char" comes from
> "character", as "bchr()" means "bytes character".

Integers 0...255 are not characters. They are ints.

`bytes.fromchar` would have to accept a string of length 1, as in:

bytes.fromchar('a') # returns b'a'

otherwise the name is completely inaccurate.

> For C programmers,

We're Python programmers. To Python programmers, the int 20 is not a
space character.


> I suggest to *not* add a builtin function bchr(), it's not common
> enough to justify to add it

Agreed, having a builtin bchr() function doesn't seem to be justified.
We can always add it in the future if needed, but using a bytes method
should be fine.


--
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/K4ZMZXWABQS5RD7OSIRFGSNJTPVRC3X2/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, Sep 08, 2021 at 05:06:08PM -0000, Brandt Bucher wrote:
> Steven D'Aprano wrote:
> > 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'
> > If that's not the API being suggested, that's going to be confusing.
>
> I'm a bit lost here... why are we convinced at all that we need a new
> way to do this? Hasn't this functionality already existed for years?
>
> >>> x = int.from_bytes(b"*", "little")
> >>> x
> 42
> >>> x.to_bytes(1, "little")
> b'*'

TIL :-)

How have I never noticed to_bytes until now? o_O


--
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QLYAHWFN5V27RKIJWTGFNYLG7KQJMJ6Q/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, Sep 09, 2021 at 12:29:46AM +0100, Rob Cliffe via Python-Dev wrote:

> Why not byte() ?

Too easy to typo it as bytes().


--
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GL5JFNJE5MH7APLG34HRUITU3GIUEBIC/
Code of Conduct: http://python.org/psf/codeofconduct/

Steven D'Aprano wrote:
> TIL :-)
> How have I never noticed to_bytes until now? o_O

I’m going to go out on a limb here: because it’s rarely ever needed?

I mean, the proposed bchr() functionality is crazy simple to implement yourself if you actually *do* need it. You can even get creative and use the dedicated “pistol” operator:

>>> b = b"*"
>>> i ,= b
>>> i
42

;)

Brandt
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AO5IOMBK2I5TSUBSRHEM75F6I3KC7AKP/
Code of Conduct: http://python.org/psf/codeofconduct/

On 9/9/21 3:49 AM, Steven D'Aprano wrote:

> We're Python programmers. To Python programmers, the int 20 is not a
> space character.

That's because int 32 is the space character. ;-)

--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6W5QDU6Q62BHTJKZG6TO634QXWD44O2F/
Code of Conduct: http://python.org/psf/codeofconduct/

Brandt Bucher wrote:
> You can even get creative and use the dedicated “pistol” operator…

Ah, wait, ignore this example. I got the chr and ord behavior flipped in my head.

Brandt
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6JWFGVLOYIIDGATFNO3YUJTZPELXOK4E/
Code of Conduct: http://python.org/psf/codeofconduct/

On 9/9/21 1:55 AM, Nick Coghlan wrote:

> `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.

I'm starting to think the name should be `bytes.bchr` -- it avoids any confusion with the `int.to_bytes` and
`int.from_bytes` methods, and is an appropriate name for the target domain (where bytes are treated as characters).

--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LR6GZQEUBD6Q3AULB7ERPHLRCGJSFM4E/
Code of Conduct: http://python.org/psf/codeofconduct/

I fully admit serious bikeshedding here, but:

I'm starting to think the name should be `bytes.bchr` -- it avoids any
> confusion with the `int.to_bytes` and
> `int.from_bytes` methods,


are they so different? :-)

In [23]: x.to_bytes(1, 'little')
Out[23]: b'A'

In [27]: int.from_bytes(b'A', 'little')
Out[27]: 65

you can think of this as a useful specific case of the int methods.

(by the way, why do I need to specify the byte order for a 1 byte int? Yes,
I know, it's always a required parameter -- though that 's one reason to
have the special case easily available)

and is an appropriate name for the target domain (where bytes are treated
> as characters).
>

Is that the target domain? Yes, it's an important use case, but
certainly not the only one, and frankly kind of a specialized use case
actually. If you are working with characters (text) in Python 3, you should
be using the str type.

Using bytes for general text (even if you know the text at hand is all
ASCII) is not recommended. It is useful to use bytes for the specialized
use case of mixed text and binary data (which, by the way, I have had to
do) but I don't think we should say that particular use case is what bytes
are targeted for. Anyone doing that should know what they are doing :-)

-CHB

--
Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

On 9/9/21 8:53 AM, Christopher Barker wrote:
> On 9/9/21 7:25 AM, Ethan Furman wrote:

>> I'm starting to think the name should be `bytes.bchr` -- it avoids any confusion with the `int.to_bytes` and
>> `int.from_bytes` methods,
>
> are they so different? :-)

Yes, they are. Conceptually, one is working with integers, the other with bytestrings (which is either entirely ASCII
encoded strings, or a mixture of the two).

>> and is an appropriate name for the target domain (where bytes are treated as characters).
>
> Is that the target domain?

Yes. PEP 467*, and PEP 461 before it, are targeting the wire format protocol domain.

--
~Ethan~


* The `fromint/bchr` portion for sure, and the other changes certainly help there although they may have wider uses.

PEP 461: https://www.python.org/dev/peps/pep-0461/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/U4HOIBFOSQGUGKFI3GGFGBFPNPIQSIH7/
Code of Conduct: http://python.org/psf/codeofconduct/

On Sep 9, 2021, at 08:53, Christopher Barker <pythonchb@gmail.com> wrote:
>
> I fully admit serious bikeshedding here, but:

I think you meant “byte-shedding” :D

-Barry

While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint().

So why don’t we just relax int.to_bytes()’s signature to include natural default values:

int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False)

Then I ought to be able to just do

>>> (65).to_bytes()
b’A’

and if I try to convert an integer value greater than 255, I get the same OverflowError?

Seems good enough to me.

-Barry

> On Sep 9, 2021, at 08:53, Christopher Barker <pythonchb@gmail.com> wrote:
>
> I fully admit serious bikeshedding here, but:
>
> I'm starting to think the name should be `bytes.bchr` -- it avoids any confusion with the `int.to_bytes` and
> `int.from_bytes` methods,
>
> are they so different? :-)
>
> In [23]: x.to_bytes(1, 'little')
> Out[23]: b'A'
>
> In [27]: int.from_bytes(b'A', 'little')
> Out[27]: 65
>
> you can think of this as a useful specific case of the int methods.
>
> (by the way, why do I need to specify the byte order for a 1 byte int? Yes, I know, it's always a required parameter -- though that 's one reason to have the special case easily available)
>
> and is an appropriate name for the target domain (where bytes are treated as characters).
>
> Is that the target domain? Yes, it's an important use case, but certainly not the only one, and frankly kind of a specialized use case actually. If you are working with characters (text) in Python 3, you should be using the str type.
>
> Using bytes for general text (even if you know the text at hand is all ASCII) is not recommended. It is useful to use bytes for the specialized use case of mixed text and binary data (which, by the way, I have had to do) but I don't think we should say that particular use case is what bytes are targeted for. Anyone doing that should know what they are doing :-)
>
> -CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/S3Q6NYRXHKUQLMP7WCQMCEEK3MCCGKNJ/
> Code of Conduct: http://python.org/psf/codeofconduct/

> I would rather keep `bchr` and lose the `.fromint()` methods.

For me, "bchr" isn't a readable name. If I expand mentally expand it to "byte_character", it becomes an oxymoron that opposes what we try teach about bytes and characters being different things.

Can you show examples in existing code of how this would be used? I'm unclear on how frequently users need to create a single byte from an integer. For me, it is very rare. Perhaps once in a large program will I search for a record separator in binary data. I would prefer to write it as:

RS = byte.fromint(30)
...
i = data.index(RS, start)
...
if RS in data:

Having this as bchr() wouldn't make the code better because it is less explicit about turning an integer into a byte. Also, it doesn't look nice when in-lined without giving it a variable name:

i = data.index(bchr(30), start) # Yuck
...
if bchr(30) in data: # Yuck

Also keep in mind that we already have a way to spell it, "bytes([30])", so any new way needs to significantly add more clarity. I think bytes.fromint() does that.

The number of use cases also matters. The bar for adding a new builtin function is very high.

Raymond
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DOUFRRLGMAFYJZ4ONYK6CKHHCYKPXJBW/
Code of Conduct: http://python.org/psf/codeofconduct/

On 9/9/21 9:37 AM, Barry Warsaw wrote:

> While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned
> about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint().
>
> So why don’t we just relax int.to_bytes()’s signature to include natural default values:
>
> int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False)
>
> Then I ought to be able to just do
>
> >>> (65).to_bytes()
> b’A’

That seems so much worse than

>>> bchr(65)
b'A'

;-)

--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2XY5B7KIODN4Q5EB6HUKVKMVOV7TPJUH/
Code of Conduct: http://python.org/psf/codeofconduct/