On Fri, 10 Sep 2021, 12:32 am Arnaud Delobelle, <arnodel@gmail.com> wrote:
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.
The getbyte() and iterbytes() methods added by the PEP make a length 1 bytes object the pseudo "byte" type, just as a length 1 string is the pseudo "character" (technically "code point") type, so "frombyte()" would have the type implications backwards (it produces a "byte", it doesn't really read one). I think it's OK for "int.from_bytes", "int.to_bytes", "bytes.fromint" and "byte array.fromint" to have closely related names, since they're closely related operations. The OverflowError raised for out of bounds values in the latter two methods could even mention int.to_bytes explicitly. While the SC already accepted "fromint", the range limitation could be made more explicit by appending "byte" to give "bytes.fromintbyte" and "bytearray.fromintbyte" (thus naming a pseudo "int byte" type for integers in the range 0-255 inclusive). An advantage of this approach is to give a specific name to the kinds of values that regular indexing and iteration of bytes objects produce. The SC has already rejected "fromord" as too obscure. I'd be OK with bytes.bchr, but bytearray.bchr would look odd to me, so I don't like that option as a whole. For "bytes.byte", I have 3 objections: * I think Greg's Smith's API stuttering concerns are valid * I think it's potentially ambiguous as to whether it is an alternate constructor or an indexed access method (i.e. doing what getbyte() does in the PEP) * I don't like it as a bytearray method name Cheers, Nick.
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/KBVVBJL2...
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/DGJWM3VM...
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/WZUPBP4U... 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/6W4G32NO... 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/P7XG5CLL... Code of Conduct: http://python.org/psf/codeofconduct/