> In my last message on this thread, I proposed to add "eu#" which > returns a Py_UNICODE buffer, possibly decoding a string object > using the given encoding first. As Martin noted, this option > requires extra copying but simplifies the C coding somewhat. Also, while it simplifies processing compared to "O", I cannot see any simplification compared to "O&". So I'd be more in favor of offering standard conversion functions for O& instead of inventing new getargs modifiers all the time. This would also simplify creation of cross-version extension modules: people could just incorporate the code of the conversion function into their code base, trusting that O& had been available for ages. 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