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.