On Sat, Sep 3, 2016 at 7:59 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 3 September 2016 at 03:54, Koos Zevenhoven <k7hoven@gmail.com> wrote:
chrb seems to be more in line with some bytes versions in for instance os than bchr.
The mnemonic for the current name in the PEP is that bchr is to chr as b"" is to "". The PEP should probably say that in addition to pointing out the 'unichr' Python 2 inspiration, though.
Thanks for explaining. Indeed I hope that unichr does not affect any naming decisions that will remain in the language for a long time.
The other big difference between this and the os module case, is that the resulting builtin constructor pairs here are str/chr (arbitrary text, single code point) and bytes/bchr (arbitrary binary data, single binary octet). By contrast, os.getcwd() and os.getcwdb() (and similar APIs) are both referring to the same operating system level operation, they're just requesting a different return type for the data.
But chr and "bchr" are also requesting a different return type. The difference is that the data is not coming from an os-level operation but from an int. 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. -- Koos
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-- + Koos Zevenhoven + http://twitter.com/k7hoven +