Michael Hudson wrote: > "Phillip J. Eby" <pje at telecommunity.com> writes: [SNIP] >>And whatever happened to CALL_METHOD? > > > It didn't work as an optimization, as far as I remember. I think the > patch is on SF somewhere. Or is a branch in CVS? Oh, it's patch > #709744. > > >>Do we need a tp_callmethod that takes an argument array, length, and >>keywords, so that we can skip instancemethod allocation in the >>common case of calling a method directly? > > > Hmm, didn't think of that, and I don't think it's how the CALL_ATTR > attempt worked. I presume it would need to take a method name too :) > CALL_ATTR basically replaced ``LOAD_ATTR; CALL_FUNCTION`` with a single opcode. Idea was that the function creation by the LOAD_ATTR was a wasted step so might as well just skip it and call the method directly. Problem was the work required to support both classic and new-style classes. Now I have not looked at the code since it was written back at PyCon 2003 and I was a total newbie to the core's C code at that point and I think Thomas said it had been two years since he did any major core hacking. In other words it could possibly have been done better. =) -Brett
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