M.-A. Lemburg writes:
> And/or perhaps sepcific APIs for each OS... e.g.
>
> PyOS_MBCSFromObject() (only on WinXX)
> PyOS_AppleFromObject() (only on Mac ;)
Another approach may be to add some format modifiers:
te -- text in an encoding specified by a C string (somewhat
similar to O&)
tE -- text, encoding specified by a Python object (probably a
string passed as a parameter or stored from some other
call)
(I'd prefer the [eE] before the t, but the O modifiers follow, so
consistency requires this ugly construct.)
This brings up the issue of using a hidden conversion function which
may create a new object that needs the same lifetime guarantees as the
real parameters; we discussed this issue a month or two ago.
Somewhere, there's a call context that includes the actual parameter
tuple. PyArg_ParseTuple() could have access to a "scratch" area where
it could place objects constructed during parameter parsing. This
area could just be a hidden tuple. When the C call returns, the
scratch area can be discarded.
The difficulty is in giving PyArg_ParseTuple() access to the scratch
area, but I don't know how hard that would be off the top of my head.
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
Corporation for National Research Initiatives
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