Passing a pointer to a function that is a class method fails.

[GoogleCodeExporter]

What steps will reproduce the problem?

1. use this input file:

#in.py

class timerevent:
    def __init__(self, func, msectime):
        self.func = func
        self.msectime = msectime

class bob:
    def __init__(self):
        self.val = 1.0

    def myprint(self):
        print "hi there"

def myfunc():
    print "hi there"

b = bob()
te = timerevent(b.myprint, 10)  # this does not work
#te = timerevent(myfunc, 10)    # this works in shedskin
te.func()

2. run shedskin

[analyzing types..]
********************************100%
[generating c++ code..]
*WARNING* in.py:4: function (class timerevent, '__init__') not called!
*WARNING* in.py:12: function (class bob, 'myprint') not called!
*WARNING* in.py:15: function myfunc not called!
*WARNING* in.py:21: class 'timerevent' has no method 'func'

What is the expected output? What do you see instead?

Expected shedskin to generate c++ file without error. 

Thanks! 

Original issue reported on code.google.com by paulhaeb...@gmail.com on 30 Jan 2013 at 7:29

Attachments:

• in.py

[GoogleCodeExporter]

thanks also for this one! unfortunately passing method references is not 
supported at the moment. please see the documentation, section 'python subset 
restrictions' for a description of this and other limitations.

the problem is that shedskin currently converts function references to C 
function pointers, which can't hold state (such as a pointer to 'self' in case 
of method references) or be easily put inside a container (such as a list). 
this was an early mistake that might be quite a bit of work to correct..

Original comment by mark.duf...@gmail.com on 30 Jan 2013 at 2:44

[GoogleCodeExporter]

Original comment by mark.duf...@gmail.com on 30 Jan 2013 at 2:45

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I had not seen that in the python subset restrictions.  I'll try to rework my 
timer code to work within the limitations.  It might not be too hard for me to 
do - I think this is the only place I try to do this.

Also, I want to say that the process of making my python code avoid dynamic 
types has actually made the code better.  Most of the places I was using 
dynamic types were not really that elegant or useful.

-p

Original comment by paulhaeb...@gmail.com on 30 Jan 2013 at 2:55

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

this is my experience with dynamic types as well. the thing I love about 
dynamic typing is not the actual dynamic typing, but the fact that you can 
leave out all the type declarations.

Original comment by mark.duf...@gmail.com on 16 Feb 2013 at 8:54

[GoogleCodeExporter]

Original comment by mark.duf...@gmail.com on 5 May 2013 at 12:54

• Changed state: WontFix