Re: [Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?
On Jun 11, 2010, at 6:57 PM, Brett Cannon wrote: > On Fri, Jun 11, 2010 at 18:30, Guido van Rossum wrote: >> On Fri, Jun 11, 2010 at 5:41 PM, Benjamin Peterson >> wrote: >>> 2010/6/11 Brett Cannon : This "magical" ignoring of self seems to extend to any PyCFunction. Is this dichotomy intentional or just a "fluke"? Maybe this is a hold-over from before we had descriptors and staticmethod, but now that we have these things perhaps this difference should go away. >>> >>> There are several open feature requests about this. It is merely >>> because PyCFunction does not implement __get__. >> >> Yeah, but this of course is because before descriptors only Python >> functions were special-cased as methods, and there was known code that >> depended on this. I'm sure there's even more code that depends on this >> today (because there is just more code, period :-). >> >> Maybe we could offer a decorator that adds a __get__ to a PyCFunction though. > > Well, staticmethod seems to work just as well. > > I'm going to make this my first request for what to change in Py4K. =) +1 on changing this, it's annoying for alternate implementations. They oftentimes implement functions in pure Python whereas user code might be expecting the PYCFunction behavior. Jython's had a couple cases of this incompatibility reported. It's a rare occurrence but it's very mysterious to the user when it happens. -- Philip Jenvey ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?
On Sat, Jun 12, 2010 at 10:19 AM, Philip Jenvey wrote: > +1 on changing this, it's annoying for alternate implementations. They > oftentimes implement functions in pure Python whereas user code might be > expecting the PYCFunction behavior. > > Jython's had a couple cases of this incompatibility reported. It's a rare > occurrence but it's very mysterious to the user when it happens. Well, yeah, but you're presenting an argument *against* changing this -- existing code will break if it is changed. I can think of only way out without just breaking such code: Start issuing warnings when a bare PyCFunction exists at the class level, and introduce/recommend decorators that can be used to disambiguate the two possible intended meanings. As Brett says, f = staticmethod(func) will work to insist on the existing PyCFunction semantics. We should also introduce a new one decorator that treats any callable the same way as pure-Python functions work today: bind the instance to the first argument when it is called on an instance. I can't think of a good name for that one right now, but we'll think of one. I wish the warning could happen at class definition time, but I expect that there are use cases where the warning is unnecessary (because the code happens to be structured so as to never call it through the instance) or even wrong (who knows what introspection might be thwarted by wrapping something in staticmethod). Perhaps the warning can be done by adding a __get__ method to PyCFunction that issues the warning and then returns the original value. I'm not sure how we'll ever get rid of the warning except in Py4k. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?
On 12 Jun 2010, at 20:59, Guido van Rossum wrote: On Sat, Jun 12, 2010 at 10:19 AM, Philip Jenvey wrote: +1 on changing this, it's annoying for alternate implementations. They oftentimes implement functions in pure Python whereas user code might be expecting the PYCFunction behavior. Jython's had a couple cases of this incompatibility reported. It's a rare occurrence but it's very mysterious to the user when it happens. Well, yeah, but you're presenting an argument *against* changing this -- existing code will break if it is changed. I can think of only way out without just breaking such code: Start issuing warnings when a bare PyCFunction exists at the class level, and introduce/recommend decorators that can be used to disambiguate the two possible intended meanings. As Brett says, f = staticmethod(func) will work to insist on the existing PyCFunction semantics. We should also introduce a new one decorator that treats any callable the same way as pure-Python functions work today: bind the instance to the first argument when it is called on an instance. I can't think of a good name for that one right now, but we'll think of one. method or instancemethod perhaps? Michael I wish the warning could happen at class definition time, but I expect that there are use cases where the warning is unnecessary (because the code happens to be structured so as to never call it through the instance) or even wrong (who knows what introspection might be thwarted by wrapping something in staticmethod). Perhaps the warning can be done by adding a __get__ method to PyCFunction that issues the warning and then returns the original value. I'm not sure how we'll ever get rid of the warning except in Py4k. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?
> method or instancemethod perhaps?
The necessary code is already in Python 3.0's code base. I've added in
in r56469 as requested in my issue http://bugs.python.org/issue1587. It
seems we had this very discussion over two and a half year ago.
Index: Python/bltinmodule.c
===
--- Python/bltinmodule.c(Revision 81963)
+++ Python/bltinmodule.c(Arbeitskopie)
@@ -2351,6 +2351,7 @@
SETBUILTIN("frozenset", &PyFrozenSet_Type);
SETBUILTIN("property", &PyProperty_Type);
SETBUILTIN("int", &PyLong_Type);
+SETBUILTIN("instancemethod",&PyInstanceMethod_Type);
SETBUILTIN("list", &PyList_Type);
SETBUILTIN("map", &PyMap_Type);
SETBUILTIN("object",&PyBaseObject_Type);
>>> class Example:
... iid = instancemethod(id)
... id = id
...
>>> Example().id()
Traceback (most recent call last):
File "", line 1, in
TypeError: id() takes exactly one argument (0 given)
>>> Example().iid()
139941157882144
Christian
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?
Hey! No borrowing the time machine! :-)
On Sat, Jun 12, 2010 at 4:03 PM, Christian Heimes wrote:
>> method or instancemethod perhaps?
>
> The necessary code is already in Python 3.0's code base. I've added in
> in r56469 as requested in my issue http://bugs.python.org/issue1587. It
> seems we had this very discussion over two and a half year ago.
>
> Index: Python/bltinmodule.c
> ===
> --- Python/bltinmodule.c (Revision 81963)
> +++ Python/bltinmodule.c (Arbeitskopie)
> @@ -2351,6 +2351,7 @@
> SETBUILTIN("frozenset", &PyFrozenSet_Type);
> SETBUILTIN("property", &PyProperty_Type);
> SETBUILTIN("int", &PyLong_Type);
> + SETBUILTIN("instancemethod", &PyInstanceMethod_Type);
> SETBUILTIN("list", &PyList_Type);
> SETBUILTIN("map", &PyMap_Type);
> SETBUILTIN("object", &PyBaseObject_Type);
>
>
class Example:
> ... iid = instancemethod(id)
> ... id = id
> ...
Example().id()
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: id() takes exactly one argument (0 given)
Example().iid()
> 139941157882144
>
> Christian
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?
(Of course, I'd still like to see the warning, since it's now a
portability issue.)
On Sat, Jun 12, 2010 at 4:15 PM, Guido van Rossum wrote:
> Hey! No borrowing the time machine! :-)
>
> On Sat, Jun 12, 2010 at 4:03 PM, Christian Heimes wrote:
>>> method or instancemethod perhaps?
>>
>> The necessary code is already in Python 3.0's code base. I've added in
>> in r56469 as requested in my issue http://bugs.python.org/issue1587. It
>> seems we had this very discussion over two and a half year ago.
>>
>> Index: Python/bltinmodule.c
>> ===
>> --- Python/bltinmodule.c (Revision 81963)
>> +++ Python/bltinmodule.c (Arbeitskopie)
>> @@ -2351,6 +2351,7 @@
>> SETBUILTIN("frozenset", &PyFrozenSet_Type);
>> SETBUILTIN("property", &PyProperty_Type);
>> SETBUILTIN("int", &PyLong_Type);
>> + SETBUILTIN("instancemethod", &PyInstanceMethod_Type);
>> SETBUILTIN("list", &PyList_Type);
>> SETBUILTIN("map", &PyMap_Type);
>> SETBUILTIN("object", &PyBaseObject_Type);
>>
>>
> class Example:
>> ... iid = instancemethod(id)
>> ... id = id
>> ...
> Example().id()
>> Traceback (most recent call last):
>> File "", line 1, in
>> TypeError: id() takes exactly one argument (0 given)
> Example().iid()
>> 139941157882144
>>
>> Christian
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?
Am 13.06.2010 01:15, schrieb Guido van Rossum: > Hey! No borrowing the time machine! :-) Too late, Guido. The keys to the time machine are back at their usual place. You should hide them better next time. ;) Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?
Guido van Rossum wrote: bind the instance to the first argument when it is called on an instance. I can't think of a good name for that one right now, but we'll think of one. dynamicmethod? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
