On Fri, 2004-02-27 at 03:20, Raymond Hettinger wrote: > My idea is for a new flag, METH_STACK, that generalizes (and potentially > replaces) METH_NOARGS AND METH_O. > > When CALL_FUNCTION sees the flag, it dispatches (*meth)(self, &stack, > numargs). You're working specifically and calls to C functions, right? The fast_funtion() path essentially does this for functions coded in Python. > On the receiving end, the arguments get retrieved with analogues to > PyArg_ParseTuple() and PyArg_UnpackTuple() which access the parameters > directly and do not need a tuple as a carrier. I like Chris's suggestion to get rid of ParseTuple() where it's still needed. The primary motivation for METH_O IIRC was to avoid the overhead of calling PyArg_ParseTuple(); the ability to eliminate the tuple overhead was gravy. There's one idea I had related to calling Python functions, not sure if it makes much sense. We push arguments onto the caller's stack then copy them into the callee's frame. I wonder if there's a way to pre-allocate the callee's frame and "push" the arguments into that frame directly. It may not make much sense, because copying the arguments from stack to frame probably isn't a big expense. Jeremy
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