[Python-Dev] buffer design

[M.-A. Lemburg]

Fredrik Lundh wrote:
> 
> Greg Stein <gstein@lyra.org> wrote:
> > > E.g. my mxTextTools
> > > package uses "s#" on many APIs. Now someone could stick
> > > in a Unicode object and get pretty strange results without
> > > any notice about mxTextTools and Unicode being incompatible.
> >
> > They could also stick in an array of integers. That supports the buffer
> > interface, meaning the "s#" in your code would extract the bytes from
> > it. In other words, people can already stick bogus stuff into your code.
> 
> Except that people may expect unicode strings
> to work just like any other kind of string, while
> arrays are surely a different thing.
> 
> I'm beginning to suspect that the current buffer
> design is partially broken; it tries to work around
> at least two problems at once:
> 
> a) the current use of "string" objects for two purposes:
> as strings of 8-bit characters, and as buffers containing
> arbitrary binary data.
> 
> b) performance issues when reading/writing certain kinds
> of data to/from streams.
> 
> and fails to fully address either of them.

True, a higher level interface for those two objectives would
certainly address them much better than what we are trying to do at
bit level. Buffers should probably only be treated as pointers to
abstract memory areas and nothing more.

BTW, what about my suggestion to extend buffers to also allocate
memory (in case you pass None as object) ? Or should array
be used for that purpose (its an undocumented feature of arrays) ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   139 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/