[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

[Nick Coghlan]

On 7 June 2016 at 15:22, Koos Zevenhoven <k7hoven at gmail.com> wrote:
> On Wed, Jun 8, 2016 at 12:57 AM, Barry Warsaw <barry at python.org> wrote:
>> On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote:
>>
>>>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky <pmiscml at gmail.com> wrote:
>>>> What's wrong with b[i:i+1] ?
>>>It always succeeds while indexing can trigger an IndexError.
>>
>> Right.  You want a method with the semantics of __getitem__() but that returns
>> the desired type.
>>
>
> And if this is called __getitem__ (with slices delegated to
> bytes.__getitem__) and implemented in a class, one has a view. Maybe
> I'm missing something, but I fail to understand what makes this
> significantly more problematic than an iterator. Ok, I guess we might
> also need __len__.

Right, it's the fact that a view is a much broader API than we need,
since most of the operations on the base type are already fine. The
two alternate operations that people are interested in are:

- like indexing, but producing bytes instead of ints
- like iteration, but producing bytes instead of ints

That said, it occurs to me that there's a reasonably strong
composability argument in favour of a view-based approach: a view will
work with operator.itemgetter() and other sequence consuming APIs,
while special methods won't. The "like-memoryview-but-not" view type
could also take any bytes-like object as input, similar to memoryview
itself.

Cheers,
Nick.

P.S. I'm starting to remember why I stopped working on this - I'm
genuinely unsure of the right way forward, so I wasn't prepared to
advocate strongly for the particular approach in the PEP :)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia