[Python-3000] need help fixing broken tests in py3k-pep3137 branch

[Nick Coghlan]

Guido van Rossum wrote:
> On 11/3/07, Jim Jewett <jimjjewett at gmail.com> wrote:
>> On 11/3/07, Guido van Rossum <guido at python.org> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org