/F writes > anyway, I think it would help the discussion a little bit > if people looked at (and played with) the existing code > base. at least that'll change arguments like "but then > we have to implement that" to "but then we have to > maintain that code" ;-) I second that. It is good enough for me (although my requirements arent stringent) - its been used on CE, so would slot directly into the win32 stuff. It is pretty much the consensus of the string-sig of last year, but as code! The only "problem" with it is the code that hasnt been written yet, specifically: * Encoders as streams, and a concrete proposal for them. * Decent PyArg_ParseTuple support and Py_BuildValue support. * The ord(), chr() stuff, and other stuff around the edges no doubt. Couldnt we start with Fredriks implementation, and see how the rest turns out? Even if we do choose to change the underlying Unicode implementation to use a different native encoding, the interface to the PyUnicode_Type would remain pretty similar. The advantage is that we have something now to start working with for the rest of the support we need. Mark.
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