Shedskin fails if there's a list of functions

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Try to compile the following code:
---------------------------------------

#!/usr/bin/env python
#-*- coding: utf-8 -*-

def foo():
  return 'hello foo'

test = [foo]

print test[0]()

---------------------------------

Works ok in python, but shedskin fails with a lot of errors during make (it
creates the c++ files without even complaining)

Here's the output of make (the file above is called "subar.py": 

#########################################################################
make
g++ -O2 -pipe -Wno-deprecated  -I.
-I/usr/lib/python2.5/site-packages/shedskin/lib
/usr/lib/python2.5/site-packages/shedskin/lib/builtin.cpp subar.cpp
/usr/lib/python2.5/site-packages/shedskin/lib/re.cpp -lgc -lpcre  -o subar

In file included from subar.hpp:4,                                        

                 from subar.cpp:1:                                        

/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp: In function
‘__shedskin__::str* __shedskin__::repr(T) [with T = __shedskin__::str*
(*)()]’:                                         
/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:1895:  
instantiated from ‘__shedskin__::str* __shedskin__::list<T>::__repr__()
[with T = __shedskin__::str* (*)()]’                 
subar.cpp:32:   instantiated from here                                    

/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:1283: error:
request for member ‘__repr__’ in ‘* t’, which is of non-class type
‘__shedskin__::str*()’                               
/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp: In function ‘int
__shedskin__::__eq(T, T) [with T = __shedskin__::str* (*)()]’:            

/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:1670:  
instantiated from ‘int __shedskin__::list<T>::__eq__(__shedskin__::pyobj*)
[with T = __shedskin__::str* (*)()]’              
subar.cpp:32:   instantiated from here                                    

/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:1295: error:
request for member ‘__eq__’ in ‘* a’, which is of non-class type
‘__shedskin__::str*()’                                 
In file included from subar.hpp:4,                                        

                 from subar.cpp:1:                                        

/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp: In function ‘int
__shedskin__::__cmp(T, T) [with T = __shedskin__::str* (*)()]’:           

/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:489:  
instantiated from ‘int
__shedskin__::pyseq<T>::__cmp__(__shedskin__::pyobj*) [with T =
__shedskin__::str* (*)()]’             
subar.cpp:32:   instantiated from here                                    

/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:214: error:
request for member ‘__cmp__’ in ‘* a’, which is of non-class type
‘__shedskin__::str*()’                                 
In file included from subar.hpp:4,                                        

                 from subar.cpp:1:
/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp: In function ‘T
__shedskin__::__deepcopy(T, __shedskin__::dict<void*,
__shedskin__::pyobj*>*) [with T = __shedskin__::str* (*)()]’:
/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:1846:  
instantiated from ‘__shedskin__::list<T>*
__shedskin__::list<T>::__deepcopy__(__shedskin__::dict<void*,
__shedskin__::pyobj*>*) [with T = __shedskin__::str* (*)()]’
subar.cpp:32:   instantiated from here
/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:1342: error:
invalid conversion from ‘__shedskin__::str* (*)()’ to ‘void*’
/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:1342: error:  
initializing argument 1 of ‘V __shedskin__::dict<K, V>::get(K, V) [with K =
void*, V = __shedskin__::pyobj*]’
/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:1846:  
instantiated from ‘__shedskin__::list<T>*
__shedskin__::list<T>::__deepcopy__(__shedskin__::dict<void*,
__shedskin__::pyobj*>*) [with T = __shedskin__::str* (*)()]’
subar.cpp:32:   instantiated from here
/usr/lib/python2.5/site-packages/shedskin/lib/builtin.hpp:1345: error:
request for member ‘__deepcopy__’ in ‘* t’, which is of non-class type
‘__shedskin__::str*()’
make: *** [subar] Error 1
#######################################################################

This happens on both debian testing with latest stable shedskin installed
from the deb, and on wine with python 2.6 and shedskin from stable
installer from windows.

BTW, shedskin is great ;)

Original issue reported on code.google.com by ssorga...@gmail.com on 18 Feb 2010 at 9:17

[GoogleCodeExporter]

thanks for reporting! unfortunately, this corresponds to a known limitation, as
mentioned in the tutorial (please see the section 'python subset 
rescrictions'). but
I will keep this issue open for a while at least, to remind me I should 
probably add
a warning for this..

interesting you used WINE. unfortunately, there are still a few known issues 
with
shedskin under WINE: http://bugs.winehq.org/show_bug.cgi?id=21388

Original comment by mark.duf...@gmail.com on 18 Feb 2010 at 7:29

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Yes, a warning would be OK, at least, for now. I was a bit skepticall when 
trying to
compile that code, and I got excited when shedskin didn't complain at all. But 
then,
make failed.

I agree it isn't that important to implement. In fact, I find an array of 
functions
is something... weird.

I was using wine for cross-compiling, which so far has worked perfectly for me. 
It
should be doable without wine and using a mingw cross-compiler directly, but I 
was
lazy :D.

I might try to compile something shedskinned with winelib if get very bored. It
*should* work if shedskin generated code compiles under mingw...

Original comment by ssorga...@gmail.com on 18 Feb 2010 at 8:11

[GoogleCodeExporter]

yeah, I have to be a bit picky about which features I spend my time on, and I 
don't
consider lists of functions to be very useful either, plus I think the current 
type
analysis would not be suitable for doing this at this point. I would probably 
prefer
to work on supporting method references first.

Original comment by mark.duf...@gmail.com on 20 Feb 2010 at 11:21

[GoogleCodeExporter]

I will leave the issue open until there is a good warning for this problem.

Original comment by mark.duf...@gmail.com on 18 Mar 2010 at 8:04

• Changed state: Accepted

[GoogleCodeExporter]

warning added, thanks again for reporting!

http://code.google.com/p/shedskin/source/detail?r=1290

Original comment by mark.duf...@gmail.com on 21 Mar 2010 at 2:32

• Changed state: Fixed