Re: [Python-3000] Unbound methods -- keep creating API?
Greg Ewing wrote: > Guido van Rossum wrote: >> They have that too. See: >> > f = list.append > g = f.__get__(a) > g >> > > Hmmm. It seems that C method objects are more > like an unbound method object that's pre-bound to a > particular class. > > I'm concerned with built-in function objects that > are *not* methods of anything. I'm suggesting they > should behave the same way as a Python function when > you put one in a class, i.e. accessing it through an > instance creates a bound method. I think I see what you're getting at now - adding a '__get__' method to the basic C function wrapper that returns self when retrieved from the class, and a bound instancemethod when retrieved from an instance. To illustrate the difference between builtin functions and methods: >>> type(str.lower) >>> '__get__' in dir(str.lower) True >>> type(map) >>> '__get__' in dir(map) False This seems like an eminently sensible idea to me, and not really something that can be done in the 2.x series. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Unbound methods -- keep creating API?
Guido van Rossum wrote: > They have, if you only consider the *important* operations. For method > descriptors the only thing you can count on is __call__. The rest are > internal implementation details -- and besides, what would you expect > im_func to be for a C function? :-) I'd just never thought about it until this discussion. I realise now that there is no particular reason for them to be the same (beyond implementing __call__). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Unbound methods -- keep creating API?
On Nov 26, 2007 10:43 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > They have that too. See: > > > f = list.append > g = f.__get__(a) > g > > > > > > Hmmm. It seems that C method objects are more > like an unbound method object that's pre-bound to a > particular class. Yes, that's exactly what an unbound method was. While for Python functions there's no compelling reason (from the VM's POV anyway) why they should only be called on instances of a particular class, for built-in functions there is a very big reason -- the C code is written assuming a specific instance lay-out. > I'm concerned with built-in function objects that > are *not* methods of anything. Like 'len', right? > I'm suggesting they > should behave the same way as a Python function when > you put one in a class, i.e. accessing it through an > instance creates a bound method. > > If that were the case, then Pyrex wouldn't have > to do anything special to create a Python class > containing a method implemented in Pyrex, and > unbound method objects could cease to exist without > causing Pyrex any problem. Couldn't PyRex define its own type for its functions that has a __get__ descriptor with the appropriate semantics? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Unbound methods -- keep creating API?
On Nov 27, 2007 2:16 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > Guido van Rossum wrote:
> >> They have that too. See:
> >>
> > f = list.append
> > g = f.__get__(a)
> > g
> >>
> >
> > Hmmm. It seems that C method objects are more
> > like an unbound method object that's pre-bound to a
> > particular class.
> >
> > I'm concerned with built-in function objects that
> > are *not* methods of anything. I'm suggesting they
> > should behave the same way as a Python function when
> > you put one in a class, i.e. accessing it through an
> > instance creates a bound method.
>
> I think I see what you're getting at now - adding a '__get__' method to
> the basic C function wrapper that returns self when retrieved from the
> class, and a bound instancemethod when retrieved from an instance.
>
> To illustrate the difference between builtin functions and methods:
>
> >>> type(str.lower)
>
> >>> '__get__' in dir(str.lower)
> True
>
> >>> type(map)
>
> >>> '__get__' in dir(map)
> False
>
> This seems like an eminently sensible idea to me, and not really
> something that can be done in the 2.x series.
On second thought (after responding to Greg), I agree that it is
sensible. But why can't it be done in 2.6?
The attached implementation is simple enough...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Index: Objects/methodobject.c
===
--- Objects/methodobject.c (revision 59193)
+++ Objects/methodobject.c (working copy)
@@ -157,6 +157,19 @@
return self;
}
+static PyObject *
+meth_descr_get(PyObject *m, PyObject *obj, PyObject *type)
+{
+ if (((PyCFunctionObject *)m)->m_self != NULL ||
+ obj == NULL || obj == Py_None)
+ {
+ Py_INCREF(m);
+ return m;
+ }
+ return PyMethod_New(m, obj);
+}
+
+
static PyGetSetDef meth_getsets [] = {
{"__doc__", (getter)meth_get__doc__, NULL, NULL},
{"__name__", (getter)meth_get__name__, NULL, NULL},
@@ -264,6 +277,8 @@
meth_getsets,/* tp_getset */
0, /* tp_base */
0, /* tp_dict */
+ meth_descr_get,/* tp_descr_get */
+ 0, /* tp_descr_set */
};
/* Find a method in a method chain */
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Unbound methods -- keep creating API?
On Nov 27, 2007 10:29 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > The attached implementation is simple enough... Do note that this breaks quite a bit of code that was storing built-in functions as class variables and accessing them via self.xxx... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Unbound methods -- keep creating API?
Guido van Rossum wrote: > Like 'len', right? Yes, anything that's a stand-alone function rather than a method of some C type. > Couldn't PyRex define its own type for its functions that has a > __get__ descriptor with the appropriate semantics? Yes, it could, but it would be more run-time support baggage to carry around in every Pyrex module that used it (there's currently no mechanism for different Pyrex modules to share runtime support code). It would be tidier if the existing builtin function type had the desired behaviour, that's all. I can't imagine there would be much in the way of existing code that would be affected by this. It would have to be putting a builtin function into a class, and then retrieving it via an instance and expecting it to come back as a plain function. But in any case, the impact on existing code could be reduced to zero by having a flag in the method descriptor to enable this behaviour. It would only be turned on for functions that really need it. -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Unbound methods -- keep creating API?
On Nov 27, 2007 4:35 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > Like 'len', right? > > Yes, anything that's a stand-alone function rather than > a method of some C type. > > > Couldn't PyRex define its own type for its functions that has a > > __get__ descriptor with the appropriate semantics? > > Yes, it could, but it would be more run-time support > baggage to carry around in every Pyrex module that used > it (there's currently no mechanism for different Pyrex > modules to share runtime support code). It would be > tidier if the existing builtin function type had the > desired behaviour, that's all. Or if there were another builtin type (wrapped around a C function obviously) with the desired behavior. > I can't imagine there would be much in the way of > existing code that would be affected by this. It would > have to be putting a builtin function into a class, > and then retrieving it via an instance and expecting > it to come back as a plain function. Funny, that. I tried my patch (see previous message) and 50 unittests had at least one failure. > But in any case, the impact on existing code could be > reduced to zero by having a flag in the method descriptor > to enable this behaviour. It would only be turned on > for functions that really need it. OK. I know you're not going to like this, but I'm asking that you provide a patch yourself. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Unbound methods -- keep creating API?
Guido van Rossum wrote: > Funny, that. I tried my patch (see previous message) and 50 unittests > had at least one failure. That's quite surprising! > I know you're not going to like this, but I'm asking that you > provide a patch yourself. Fair enough. I'll file this idea away for when I get around to working on Pyrex3k. -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
