*de-lurks* On Mon, Jul 18, 2016 at 4:45 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Mon, Jul 18, 2016 at 4:17 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
- 'bytes.zeros' renamed to 'bytes.size', with option byte filler (defaults to b'\x00')
Seriously? You went from a numpy-friendly feature to something rather numpy-hostile. In numpy, ndarray.size is an attribute that returns the number of elements in the array.
The constructor that creates an arbitrary repeated value also exists and is called numpy.full().
Even ignoring numpy, bytes.size(count, value=b'\x00') is completely unintuitive. If I see bytes.size(42) in someone's code, I will think: "something like int.bit_length(), but in bytes."
full(), despite its use in numpy, is also unintuitive to me (my first thought is that it would indicate whether an object has room for more entries). Perhaps bytes.fillsize? That would seem the most intuitive to me: "fill an object of this size with this byte". I'm unfamiliar with numpy, but a quick Google search suggests that this would not conflict with anything there, if that is a concern.
This PEP isn't revisiting that original design decision, just changing the spelling as users sometimes find the current behaviour of the binary sequence constructors surprising. In particular, there's a reasonable case to be made that ``bytes(x)`` (where ``x`` is an integer) should behave like the ``bytes.byte(x)`` proposal in this PEP. Providing both behaviours as separate class methods avoids that ambiguity.
You have a leftover bytes.byte here.