At 04:35 PM 12/11/03 +0000, Duncan Booth wrote: >The way I was planning to do function calls (and had partially implemented >it), was to have an IPyCallable interface, and a set of classes that >implement that interface. > >The interface includes methods: > > PyObject __call__(); > PyObject __call__(PyObject arg1); > PyObject __call__(PyObject arg1, PyObject arg2); > PyObject __call__(PyObject arg1, PyObject arg2, PyObject arg3); > PyObject __call__(PyObject[] args); > PyObject __call__(PyObject[] args, PyDict keywordArgs); > >Concrete classes exist for functions and for bound methods taking 0, 1, 2, >3 or more arguments. The constructor for a function object takes a >delegate, a list of argument names and a list of defaults. Hm. We could steal this exact same idea for use in CPython, although it'd be tedious to implement. The current tp_call would cover the last two cases shown, but adding a tp_call0 through tp_call3 or so might speed up a *lot* of function calls. Specialized bytecodes for these calls would have very short implementations. The tp_call_N slots could have default implementations in 'object' that delegate back to the regular tp_call, so that end-user types wouldn't need to reimplement them. Hm. Actually, this'd be *really* tedious to implement right, because of all the custom bound method types needed, and the C multiple wrappers for __call__ methods written in Python. OTOH, this might be an "opportunity" to write generic leftcurry and rightcurry functions, and use rightcurry for default arguments... Bleah. What this *really* seems to want is to generate a new type on the fly, that is precisely coded to do the necessary left and right currying as part of C-level code invocation. A JIT, in other words. Ah well, it sounded cool at first. :)
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