On 7 June 2016 at 15:22, Koos Zevenhoven firstname.lastname@example.org wrote:
On Wed, Jun 8, 2016 at 12:57 AM, Barry Warsaw email@example.com wrote:
On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote:
On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky firstname.lastname@example.org 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.
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 :)