On 4 September 2016 at 08:11, Random832 <random832@fastmail.com> wrote:
On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote:
I guess one reason I don't like bchr (nor chrb, really) is that they look just like a random sequence of letters in builtins, but not recognizable the way asdf would be.
I guess I have one last pair of suggestions for the name of this function: bytes.chr or bytes.char.
The PEP started out with a classmethod, and that proved problematic due to length and the expectation of API symmetry with bytearray. A new builtin paralleling chr avoids both of those problems.
What about byte? Like, not bytes.byte, just builtins.byte.
The main problem with "byte" as a name is that "bytes" is *not* an iterable of these - it's an iterable of ints. That concern doesn't arise with chr/str as they're both abbreviated singular nouns rather than one being the plural form of the other (it also doesn't hurt that str actually is an iterable of chr results). If we wanted a meaningful noun (other than byte) for the bchr concept, then the alternative term that most readily comes to mind for me is "octet", but I don't know how intuitive or memorable that would be for folks without an embedded systems or serial communications background (especially given that we already have 'oct', which does something completely different). That said, the PEP does propose "getbyte()" and "iterbytes()" for bytes-oriented indexing and iteration, so there's a reasonable consistency argument in favour of also proposing "byte" as the builtin factory function: * data.getbyte(idx) would be a more efficient alternative to byte(data[idx]) * data.iterbytes() would be a more efficient alternative to map(byte, data) With bchr, those mappings aren't as clear (plus there's a potentially unwanted "text" connotation arising from the use of the "chr" abbreviation). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia