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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4