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. </F>
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