> While we're on the topic -- Guid, how would you feel about the
> idea of giving built-in function objects the same instance-
> binding behaviour as interpreted functions?
>
> This would help Pyrex considerably, because currently I
> have to resort to a kludge to make Pyrex-defined functions
> work as methods. It mostly works, but it has some side
> effects, such as breaking the most common idiomatic
> usage of staticmethod() and classmethod().
>
> If built-in functions were more like interpreted functions
> in this regard, all these problems would go away.
There are two ways to "bind" a built-in function to an object.
One would be to do what happens for Python functions, which is in
effect a currying: f.__get__(obj) yields a function g that when called
as g(arg1, ...) calls f(obj, arg1, ...). (In fact, I've recently
checked in a change that makes instancemethod a general currying
function on the first argument. :-)
But the other interpretation, which might be more appropriate for C
functions, is that the bound instance is passed to the first argument
at the *C* level, usually called self:
PyObject *
my_c_function(PyObject *self, PyObject *args)
{
...
}
Which one would you like? I think we could do each rather easily
(perhaps the first more easily because the type needed to represent
the bound method already exist; for the second I think we'd have to
introduce a new helper object type).
--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