> > For better or for worse, the distinction between a function and a
> > bound method is gone by the time it's called, and recovering that
> > difference is going to be tough. Not in terms of serious overhead,
> > but in terms of serious changes to code that is already extremely
> > subtle. That code it's so subtle *because* we want to keep function
> > call overhead as low as possible, and anything that would add even a
> > fraction of a microsecond to the cost of calling a function with the
> > correct number of arguments will be scrutinized to death.
>
> Agreed. I just looked at the code to see why. Its much more
> difficult than I imagined (except in one easy looking case in ceval.c).
>
> For anyone who hasn't read the code, the Python/getargs.c vgetargs1()
> function that parses the argument description string has no knowledge
> of the PyCFunction object its checking arguments for. Major restruring
> to do this could be done several ways but is a huge task for speed and
> C interface compatibility reasons.
Um, when is this a problem for methods implemented in C? AFAIK the
problem only exists for Python methods: take e.g. append() as an
example of a C method, and everything is fine:
>>> [].append(1,2 )
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: append() takes exactly one argument (2 given)
>>>
The issue is really in ceval.c...
--Guido van Rossum (home page: http://www.python.org/~guido/)
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