[Python-Dev] PEP 467: Minor API improvements for bytes & bytearray

[Raymond Hettinger]

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>