On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > There are two self-consistent sets of names: >
Let me add a few. I wonder if this is really used so much that bytes.chr is too long to type (and you can do bchr = bytes.chr if you want to): bytes.chr (or bchr in builtins) bytes.chr_at, bytearray.chr_at bytes.iterchr, bytearray.iterchr bytes.chr (or bchr in builtins) bytes.chrview, bytearray.chrview (sequence views) bytes.char (or bytes.chr or bchr in builtins) bytes.chars, bytearray.chars (sequence views) > bchr > bytes.getbchr, bytearray.getbchr > bytes.iterbchr, bytearray.iterbchr > > byte > bytes.getbyte, bytearray.getbyte > bytes.iterbytes, bytearray.iterbytes > > The former set emphasises the "stringiness" of this behaviour, by > aligning with the chr() builtin > > The latter set emphasises that these APIs are still about working with > arbitrary binary data rather than text, with a Python "byte" > subsequently being a length 1 bytes object containing a single integer > between 0 and 255, rather than "What you get when you index or iterate > over a bytes instance". > > Having noticed the discrepancy, my personal preference is to go with > the latter option (since it better fits the "executable pseudocode" > ideal and despite my reservations about "bytes objects contain int > objects rather than byte objects", that shouldn't be any more > confusing in the long run than explaining that str instances are > containers of length-1 str instances). The fact "byte" is much easier > to pronounce than bchr (bee-cher? bee-char?) also doesn't hurt. > > However, I suspect we'll need to put both sets of names in front of > Guido and ask him to just pick whichever he prefers to get it resolved > one way or the other. > >> And didn't someone recently propose deprecating iterability of str >> (not indexing, or slicing, just iterability)? Then str would also need >> a way to provide an iterable or sequence view of the characters. For >> consistency, the str functionality would probably need to mimic the >> approach in bytes. IOW, this PEP may in fact ultimately dictate how to >> get a iterable/sequence from a str object. > > Strings are not going to become atomic objects, no matter how many > times people suggest it. > You consider all non-iterable objects atomic? If str.__iter__ raises an exception, it does not turn str somehow atomic. I wouldn't be surprised by breaking changes of this nature to python at some point. The breakage will be quite significant, but easy to fix. -- Koos _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
