On 7 June 2016 at 15:22, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Wed, Jun 8, 2016 at 12:57 AM, Barry Warsaw <ba...@python.org> wrote: >> On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote: >> >>>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky <pmis...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
