On 11/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > 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 >
All seem fine to me. But I am also okay with Paul's suggestion of ByteSequence. -Brett > --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/brett%40python.org > _______________________________________________ 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
