the three types: function, classmethod, staticmethod are descriptors.
but staticmethod's __get__ return the orignal value, others return
object of instancemethod. (from souce in Objects/funcobject.c)
so the staticmethod just like a wrap that make the wrapped object
'frozen'. like in your example.
P.J. Eby wrote:
At 08:50 PM 9/1/2009 -0400, Terry Reedy wrote:
Greg Ewing wrote:
Benjamin Peterson wrote:
It depends on whether you're keeping the "callable" object around or
not. Somebody could add a __call__ method later.
Good point. Removing the check sounds like the
right thing to do, th
At 08:50 PM 9/1/2009 -0400, Terry Reedy wrote:
Greg Ewing wrote:
Benjamin Peterson wrote:
It depends on whether you're keeping the "callable" object around or
not. Somebody could add a __call__ method later.
Good point. Removing the check sounds like the
right thing to do, then.
Both classm
Greg Ewing wrote:
Benjamin Peterson wrote:
It depends on whether you're keeping the "callable" object around or
not. Somebody could add a __call__ method later.
Good point. Removing the check sounds like the
right thing to do, then.
Both classmethod & staticmethod are documented as having a
On Sep 1, 2009, at 2:54 PM, Benjamin Peterson wrote:
2009/9/1 Brett Cannon :
On Tue, Sep 1, 2009 at 07:21, Benjamin
Peterson wrote:
2009/8/31 xiaobing jiang :
My idea is: here, the two functions (or maybe classes) should
have the
same behavior).
so is this a bug or something I missing ?
Benjamin Peterson wrote:
It depends on whether you're keeping the "callable" object around or
not. Somebody could add a __call__ method later.
Good point. Removing the check sounds like the
right thing to do, then.
--
Greg
___
Python-Dev mailing lis
2009/9/1 Greg Ewing :
> Brett Cannon wrote:
>>
>> It isn't like it is checking
>> explicitly for a function or method, just that it can be called which
>> seems reasonable to me (unless PyCallable_Check() is as off as
>> callable() was).
>
> I think it just checks that there's something in the
> tp
Brett Cannon wrote:
It isn't like it is checking
explicitly for a function or method, just that it can be called which
seems reasonable to me (unless PyCallable_Check() is as off as
callable() was).
I think it just checks that there's something in the
tp_call slot, which is reasonable -- if it'
On Tue, Sep 1, 2009 at 14:54, Benjamin Peterson wrote:
> 2009/9/1 Brett Cannon :
>> On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote:
>>> 2009/8/31 xiaobing jiang :
My idea is: here, the two functions (or maybe classes) should have the
same behavior).
so is this a bug or somethi
2009/9/1 Brett Cannon :
> On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote:
>> 2009/8/31 xiaobing jiang :
>>> My idea is: here, the two functions (or maybe classes) should have the
>>> same behavior).
>>> so is this a bug or something I missing ?
>>
>> I think they should both not check their
On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote:
> 2009/8/31 xiaobing jiang :
>> My idea is: here, the two functions (or maybe classes) should have the
>> same behavior).
>> so is this a bug or something I missing ?
>
> I think they should both not check their arguments in __init__ to
> allow
2009/8/31 xiaobing jiang :
> My idea is: here, the two functions (or maybe classes) should have the
> same behavior).
> so is this a bug or something I missing ?
I think they should both not check their arguments in __init__ to
allow for duck typing.
--
Regards,
Benjamin
__
hi all:
In the svn thunk tree, I find in file Object/funcobject.c, the two
functions: sm_init and cm_init have a little different. the cm_init
function will check the object is really callable, but the sm_init
don't.
the code like this:
if (!PyCallable_Check(callable)) {
PyErr_Format(Py
13 matches
Mail list logo
