On Aug 17, 2014, at 4:08 PM, Nick Coghlan <[email protected]> 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
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
