[Python-Dev] PEP 467: last round (?)

[Nick Coghlan]

On 4 September 2016 at 08:11, Random832 <random832 at 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 at gmail.com   |   Brisbane, Australia