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

tritium-list at sdamon.com tritium-list at sdamon.com
Tue Jun 7 17:50:49 EDT 2016

-----Original Message----- From: Python-Dev [mailto:python-dev-bounces+tritium-_ _list=sdamon.com at python.org] On Behalf Of Nick Coghlan Sent: Tuesday, June 7, 2016 5:40 PM To: Barry Warsaw <barry at python.org> Cc: python-dev at python.org Subject: Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 7 June 2016 at 14:31, Barry Warsaw <barry at python.org> wrote: > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > >>* Add bytes.iterbytes, bytearray.iterbytes and >> memoryview.iterbytes alternative iterators > > +1 but I want to go just a little farther. > > We can't change bytes.getitem but we can add another method that returns > single byte objects? I think it's still a bit of a pain to extract single > bytes even with .iterbytes(). > > Maybe .iterbytes can take a single index argument (blech) or add a method like > .byteat(i). I'll let you bikeshed on the name. Perhaps: data.getbyte(i) data.iterbytes()

data.getbyte(index_or_slice_object) ?

while it might not be... ideal... to create a sliceable live view object, we can have a method that accepts a slice, even if we have to create it manually (or at least make it convenient for those who wish to wrap a bytes object in their own type and blindly pass the first-non-self arg of a custom getitem to the method).

The rationale for "Why not a live view?" is that an iterator is simple to define and implement, while we know from experience with memoryview and the various dict views that live views are a minefield for folks defining new container types. Since this PEP would in some sense change what it means to implement a full "bytes-like object", it's worth keeping implementation complexity in mind.

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

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium- list%40sdamon.com

More information about the Python-Dev mailing list