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/archive%40mail-archive.com
