[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
Nick Coghlan
ncoghlan at gmail.com
Tue Jun 7 17:39:30 EDT 2016
More information about the Python-Dev mailing list
Tue Jun 7 17:39:30 EDT 2016
- Previous message (by thread): [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
- Next message (by thread): [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 > .byte_at(i). I'll let you bikeshed on the name. Perhaps: data.getbyte(i) data.iterbytes() 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
- Previous message (by thread): [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
- Next message (by thread): [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list