I'm beginning to settle on the following: 1. concrete types: bytes (immutable) and bytearray (mutable) 2. their common ABC: ByteString (derives from Sequence) 3. the ABC corresponding to buffer-API objects: MemoryBlock
--Guido On 11/3/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > Those look clearly better than the previous suggestions to me. +1. > > I think 'bytelist' is more correct than 'byteslist'. But it's not a list, it's a sequence. :-) > It's a list of > 'byte's rather than a list of 'bytes'es. Which isn't particularly > convincing... Maybe the fact that we say "chicken farm" instead of > "chickens farm" is better? I think this is a specifically English > convention for pluralization that's different in many other languages. > > On 11/3/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > > > On 11/3/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > > >> On 11/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > >>> I'd love a better term. It seems we could use several new names: > > >>> 1. a new name for what PEP 3137 calls buffer > > >> ByteBuffer > > > > > > Fails the rule that built-in types have all-lowercase names. I've been > > > thinking to call it bytesbuffer or bytes_buffer though. > > > > bytelist or byteslist? (It combines the mutable nature of a list with > > the other characteristics of the bytes type, after all) > > > > >>> 2. a new name for the union of bytes and buffer (*) > > >> ByteSequence > > > > > > That could work, it's an ABC after all (to be imported from collections). > > > > ByteSequence works for me (I believe it has been suggested at least once > > before) > > > > >>> 3. a new name for all types supporting the "buffer API" > > >> buffer > > > > > > Another ABC, so should have a CamelCase name. Also, we probably > > > shouldn't use plain, unadorned "buffer" or "Buffer" for any of these > > > -- it has too many meanings. Also "buffer" is a popular variable name > > > (much more so than bytes). > > > > BinaryData? When using the enhanced buffer API, an object may be > > exposing binary data formatted in the specified format rather than just > > basic bytes. > > > > So the 'buffer API' would become the 'binary data API', and in cases > > where it mattered (such as the constructors for binary data types like > > array.array) the binary data interface would take precedence over the > > iterable interface. Coming from a comms background where "buffer" means > > "FIFO queue" most of the time, it would also be a lot more intuitive. > > > > Cheers, > > Nick. > > > > -- > > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > > --------------------------------------------------------------- > > http://www.boredomandlaziness.org > > _______________________________________________ > > Python-3000 mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-3000 > > Unsubscribe: > > http://mail.python.org/mailman/options/python-3000/jyasskin%40gmail.com > > > > > -- > Namasté, > Jeffrey Yasskin > http://jeffrey.yasskin.info/ > > "Religion is an improper response to the Divine." — "Skinny Legs and > All", by Tom Robbins > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
