MAL wrote: > Jack Jansen wrote: > > > > I had expected the PyArg_ParseTuple() "u" specifier to automatically convert > > string objects to unicode strings with the default encoding (just as the > > reverse is true for "s"), but to my surprise it doesn't. > [...] > > I could imagine extending the "u" parser marker to do the same > using an temporary Unicode object the contents of which are then > copied into a user provided buffer (much like what "es#" does). > Alternatively, we could extend the "e" parser marker with a > "u" target... this has the added benefit of being able > to define an encoding to use for dealing with non-Unicode > string data. I like this second alternative, because it also provides a possible solution for a more complex problem I have. I'm porting the PythonWin MFC modules to Windows CE, and on WinCE the OS API's are completely unicode-based. In C you can write code that is portable between 8-bit systems and Unicode systems by using a set of macros and types that get expanded to char/strlen/sprintf/etc or wchar_t/wslen/etc. Currently I have every PyArg_ParseTuple #ifdeffed, but using an "e" marker would be better. > If you think this is needed, please upload a feature request to > SF and assign it to me. I'll look into this after the feature > freeze then. As I'm doing this project with a very old Python I might as well do it myself (unless I can't figure out how:-), and then I'll put the patch in sourceforge, hand it over to you and you can turn my gibberish into real C:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
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