[Python-Dev] PEP 467: Minor API improvements for bytes & bytearray (original) (raw)

Raymond Hettinger raymond.hettinger at gmail.com
Mon Aug 18 01:41:38 CEST 2014

On Aug 17, 2014, at 4:08 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

Purely deprecating the bytes case and leaving bytearray alone would likely address my concerns.

That is good progress. Thanks :-)

Would a warning for the bytes case suffice, do you need an actual deprecation?

bytes.byte() thus becomes the binary equivalent of chr(), just as Python 2 had both chr() and unichr().

I don't recall ever needing chr() in a real program either, but I still consider it an important part of clearly articulating the data model.

"I don't recall having ever needed this" greatly weakens the premise that this is needed :-)

The APIs have been around since 2.6 and AFAICT there have been zero demonstrated need for a special case for a single byte. We already have a perfectly good spelling:

NUL = bytes([0])

The Zen tells us we really don't need a second way to do it (actually a third since you can also write b'\x00') and it suggests that this special case isn't special enough.

I encourage restraint against adding an unneeded class method that has no parallel elsewhere. Right now, the learning curve is mitigated because bytes is very str-like and because bytearray is list-like (i.e. the method names have been used elsewhere and likely already learned before encountering bytes() or bytearray()). Putting in new, rarely used funky method adds to the learning burden.

If you do press forward with adding it (and I don't see why), then as an alternate constructor, the name should be from_int() or some such to avoid ambiguity and to make clear that it is a class method.

iterbytes() isn't especially attractive as a method name, but it's far more explicit about its purpose.

I concur. In this case, explicitness matters.

Raymond

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140817/0bfa3ee0/attachment.html>

More information about the Python-Dev mailing list