> Both of these implementation are targetted at providing > a file IO like interface to in-memory "files". Since Python > file object don't magically support Unicode, I wonder where the > idea came from that StringIO/cStringIO should. The exact source of this idea is unknown. However, there are many early references to it: - codecs.open returns an "encoded file" which "will only accept ... Unicode objects". That is perhaps the earliest precedent of a file object supporting Unicode. - At some point in time, you said that it is a bug that cStringIO does not support Unicode strings, see http://mail.python.org/pipermail/i18n-sig/2000-November/000550.html - the documentation of StringIO suggests that they should accept Unicode. So I would not blame the users for adopting far-off ideas, when the Python core itself suggests that these ideas are Pythonic. > That patch I applied to StringIO/cStringIO for 2.2 was > aimed at making these two more compatible to the standard > Python file object. The latter uses the "s#" parser > marker for .write() and thus can also accept memory > buffers. This was previously not possible with either > of the two StringIO implementation (StringIO.py failed > when trying to join different buffer compatible objects, > cStringIO only accepted real string objects). There is nothing wrong with that. The patch should just have special-cased Unicode objects (and that bug can still be corrected). Regards, Martin
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