I see in the PEP:

"the bchr builtin is to recreate the ord/chr/unichr trio from Python 2 under a different naming scheme"

Why recreate that trio? Shouldn't we be moving away from the bytes-is-a-string concept here?

A byte is not a character -- why would the function that creates a byte from an integer value be called bchr()? (short for "byte character", presumably)

There are fewer and fewer people having to translate their code (or their brains) from py2 to py3.

bytes.fromint() is just fine.

-CHB

BTW -- I really love the rest of the PEP -- it's been too awkward to work with bytes for too long.

On Wed, Aug 4, 2021 at 9:43 AM Barry Warsaw <barry@python.org> wrote:

On Aug 4, 2021, at 07:31, Victor Stinner <vstinner@python.org> wrote:
>
> On Tue, Aug 3, 2021 at 7:54 PM Ethan Furman <ethan@stoneleaf.us> wrote:
>> I would rather keep `bchr` and lose the `.fromint()` methods.
>
> I would prefer to only have a bytes.byte(65) method, no bchr()
> built-in function. I would prefer to keep builtins namespace as small
> as possible.

The Steering Council is also pretty adamantly against adding a new bchr() built-in.

> bytes.byte() name is similar to bytes.getbyte(). I cannot find "int"
> in the name of other bytes methods.

.byte() seems fine to me too. I’m not a fan of smushedwords but .fromint() seemed better than .fromord().

-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/CPZTRWIWLRKTBHQS6UPY63BEZCV3FDZZ/
Code of Conduct: http://python.org/psf/codeofconduct/