On Sun, 22 Aug 2021 16:08:56 -0700 Guido van Rossum <gu...@python.org> wrote: > Hm, I don’t think the major use for bchr() will be with a constant.
What would be the major use for bchr()? I don't think I've ever regretted its absence. Regards Antoine. > > On Sun, Aug 22, 2021 at 14:48 Gregory P. Smith <g...@krypto.org> wrote: > > > > > On Tue, Aug 10, 2021 at 3:48 PM Christopher Barker <python...@gmail.com> > > wrote: > > > >> On Tue, Aug 10, 2021 at 3:00 PM <raymond.hettin...@gmail.com> wrote: > >> > >>> The history of bytes/bytearray is a dual-purpose view. It can be used > >>> in a string-like way to emulate Python 2 string handling (hence all the > >>> usual string methods and a repr that displays in a string-like fashion). > >>> It can also be used as an array of numbers, 0 to 255 (hence the list > >>> methods and having an iterator of ints). ISTM that the authors of this > >>> PEP > >>> reject or want to discourage the latter use cases. > >>> > >> > >> I didn't read it that way, but if so, please no, I"d rather see the > >> former use cases discouraged. ISTM that the Py2 string handling is still > >> needed for working with mixed binary / text data -- but that should be a > >> pretty specialized use case. spelling the way to create a byte, byte() sure > >> makes more sense in any other context. > >> > >> > >>> ... anything where a C programmer would an array of unsigned chars). > >>> > >> > >> or any programmer would use an array of unsigned 8bit integers :-) numpy > >> spells it: `np.uint8`, and the the type in the C99 stdint.h is `uint8_t`. > >> My point is that for anyone not an "old time" C programmer, or even a > >> Python2 programmer, the "character is an unsigned 8 bit int" concept is > >> alien and confusing, not a helpful mnemonic. > >> > >> > >>> For example, creating a single byte with bytes([0x1f]) isn't pleasant, > >>> obvious, or fast. > >>> > >> > >> no, though bytes([31]) isn't horrible ;-) (despite coding for over four > >> decades, I'm still not comfortable with hex notation) > >> > >> I say it's not horrible, because bytes is a Sequence of bytes (or integer > >> values between 0 and 255), initializing it with an iterable seems pretty > >> reasonable, that's how we initialize most (all?) other sequences after all. > >> And compatible with array.array and numpy arrays. > >> > > > > I consider bytes([31]) notation to be horrible API design because a simple > > easy to make typo of omitting the [] or using () and forgetting the > > tupleizing comma turns it into a different valid call with an entirely > > different meaning. bytes([31]) vs bytes((31)) vs bytes(31). > > > > It's also ugly to anyone who thinks about what bytecode is generated and > > executed in order to do it. an entire new list object with a single > > element referring to a tiny int is created and destroyed just to create a > > b'\037' object? An optimizer pass to fix that up at the bytecode level > > isn't easy as it can only be done when it can prove that `bytes` has not > > been reassigned to something other than the builtin. Near impossible in a > > lot of code. bytes.fromint(31) isn't much better in the bytecode regard, > > but at least a temporary list is not being created. > > > > As much as I think that bytes(size: int) was a bad idea to have as an API > > - bytearray(size: int) is fine and useful as it is mutable - that ship > > sailed and getting rid of it would break some odd code. It doesn't have > > much use, so adding fromsize(size: int) methods don't sound very compelling > > as it just adds yet another way to do the same thing. we should just live > > with that specific wart. > > > > `bchr` as a builtin... I'm with the others on saying no to any new builtin > > that isn't expected to see frequent use. bchr won't see frequent use. > > > > `bytes.fromint` seems fine. others are proposing `bytes.byte` for that. > > I don't *like* to argue over names (the last stage of anything) but I do > > need to point out how that sounds to read. It falls victim to API > > stuttering. "bytes dot byte" or "bytes byte" doesn't convey much to a > > reader in English as the difference is a subtle "s". "bytes dot from int" > > or "bytes from int" is quite clear. (avoiding stuttering in API design was > > popularized by golang - it's a good thing to strive for in any language) > > It's times like this that i wish Python had chosen consistent camelCase, > > CapWords, or snake_case in all API names as conjoinedwords aren't great. > > But they are sadly consistent with our past sins. > > > > One thing never mentioned in the PEP. If you expect a primary use of the > > fromint (aka bchr builtin that isn't going to happen) to be called on > > constant values often. Why are we adding name lookups and function calls > > to this? Why not address the elephant in the room and allow for decimal > > values to be written as an escape sequence within bytes literals? > > > > b'\d31' for example to say "decimal byte 31". Proposal: Only values 0-255 > > with no leading zero should be accepted when parsing such an escape. (Do > > not bother adding the same feature for codepoints in unicode strs; leave > > that to later if someone shows actual demand). This can't address the > > bytearray need, but that's been true of bytearray for ages, a common way to > > create them is via a copy from transient bytes objects. bytearray(b'\d31') > > isn't much different than bytearray.fromint(31). one less name lookup. > > > > Why not add a \d escape? Introducing a new escape is fraught with peril as > > existing \d's within b'' literals in code could change meaning. backwards > > compatibility fail. But one that is easy to check for with a > > DeprecationWarning for a few releases... The new literal parsing could be > > enabled per-file with a __future__ import. > > > > -gps > > > > > >> -CHB > >> > >> > >> -- > >> Christopher Barker, PhD (Chris) > >> > >> Python Language Consulting > >> - Teaching > >> - Scientific Software Development > >> - Desktop GUI and Web Development > >> - wxPython, numpy, scipy, Cython > >> _______________________________________________ > >> Python-Dev mailing list -- python-dev@python.org > >> To unsubscribe send an email to python-dev-le...@python.org > >> https://mail.python.org/mailman3/lists/python-dev.python.org/ > >> Message archived at > >> https://mail.python.org/archives/list/python-dev@python.org/message/RM4JHK4GIKYYWV7J5F6IQJ66KUIXWMMF/ > >> Code of Conduct: http://python.org/psf/codeofconduct/ > >> > > _______________________________________________ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > > https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AA2DIRNNCSGVYDHZG2LMP3OOQRRL3IAN/ Code of Conduct: http://python.org/psf/codeofconduct/
