Class variable error when inheritance occured accross different files

[GoogleCodeExporter]

Class variable error when inheritance occured accross different files
Maybe namespace issue
SS Ver: r1451
The following 2 files can't compile when testb.py start with "import 
testa" and "from testa import aa", but works well with "from testa import 
*" 
If we remove the class helper and the helper.enable in aa.__init__(), then 
they can't compile when testb.py start with "import testa", but works well 
with "from testa import aa" and  "from testa import *" 

In normal usage scenario, all 3 above "import" cases should work

Details:

root@ubuntu10-64:~/tools/test# cat testa.py

class helper():
  flag=0
  @staticmethod
  def enable():
    helper.flag=1

class aa():
  #class_var1={}
  class_var2=0
  def __init__(self):
    helper.enable()
    aa.class_var2=1
    print "init a"
    temp=[1,2]
    #aa.class_var1.update({'a':bb()})
    for i in temp:
      print i

root@ubuntu10-64:~/tools/test# cat testb.py
from testa import aa
class b(aa):
  pass
instance=b()

root@ubuntu10-64:~/tools/test# shedskin testb
*** SHED SKIN Python-to-C++ Compiler 0.5 ***
Copyright 2005-2010 Mark Dufour; License GNU GPL version 3 (See LICENSE)

[iterative type analysis..]
**
iterations: 2 templates: 61
[generating c++ code..]
*WARNING* testa.py:11: class 'helper' has no method 'enable'

root@ubuntu10-64:~/tools/test# make
g++  -O0 -pipe -Wno-deprecated  -I. -I/usr/local/lib/python2.6/dist-
packages/shedskin/lib testa.cpp /usr/local/lib/python2.6/dist-
packages/shedskin/lib/builtin.cpp testb.cpp /usr/local/lib/python2.6/dist-
packages/shedskin/lib/re.cpp -lgc -lpcre  -o testb
testa.cpp: In static member function ‘static void* 
__testa__::helper::enable()’:
testa.cpp:19: error: ‘class __shedskin__::class_’ has no member named 
‘flag’
testa.cpp: In member function ‘void* __testa__::aa::__init__()’:
testa.cpp:37: error: ‘class __shedskin__::class_’ has no member named 
‘enable’
make: *** [testb] Error 1

Original issue reported on code.google.com by jason.mi...@gmail.com on 16 May 2010 at 3:31

[GoogleCodeExporter]

test case note:
when use "import testa" in testb.py, the class b definition should be changed 
accordingly:
class b(testa.aa):
  pass

Original comment by jason.mi...@gmail.com on 16 May 2010 at 3:41

[GoogleCodeExporter]

is it clear I usually test single-file programs..? :) 

but thanks. I will try to have a look at this soon..

Original comment by mark.duf...@gmail.com on 16 May 2010 at 8:35

• Changed state: Accepted

[GoogleCodeExporter]

btw, are you extracting things from a larger program? if so, I'd be interested 
in
adding this program to the example set.

Original comment by mark.duf...@gmail.com on 16 May 2010 at 10:16

[GoogleCodeExporter]

Yes, that issue comes from a relatively larger system. :), I noticed that from 
the 
test case collection. Please add these test cases to the example set.
I think it's common to involve multiple files in an object oriented design, 
each 
class has a file, modularity and capabilibty to design large system are very 
important features for python. SS is very good to compile small program, but if 
we 
can resolve the scalability issue, it must be a tremendous contribution to 
python 
community.
I'm developing a complex computing intensive system using python, hoping to use 
SS 
to improve performance. Currently SS works only when I put all codes in one 
file. 
Maybe some namespace issues exist. 
I'm pleased to help you fix these issues. 
Thanks for the fabulous shedskin :)

Original comment by jason.mi...@gmail.com on 16 May 2010 at 11:10

[GoogleCodeExporter]

no I mean the whole system, would it be possible to add that as an example 
program..? ;)

okay, this uncovered a nasty unknown problem, where (global) variable lookups 
are
done in the wrong module, for methods that are inherited across modules.. I 
fixed
this case, but it will take some time to fix several other related cases. 
please let
me know if you run into any other problems!

again, please verify so I can close this one.. and thanks again for reporting! 
:D

Original comment by mark.duf...@gmail.com on 16 May 2010 at 4:13

[GoogleCodeExporter]

Test done, issue fixed
Currently this system is under development and it's a proprietary software in a 
company. I'm afraid these will be some legal issues to open it. 
I'm trying to make it compatible with both cpython and SS when developing. And 
I'll 
report any problems encountered.
Thanks for the fix. :)

Original comment by jason.mi...@gmail.com on 17 May 2010 at 12:05

[GoogleCodeExporter]

sure, I understand!

is shedskin perhaps also potentially useful for you because of the relatively
thorough obfuscation that results from native compilation?

thanks again for reporting and verifying. I will look at the class attribute
dictionary problem next.. hopefully in the next few days, otherwise in the 
weekend. 

closing this one then..

Original comment by mark.duf...@gmail.com on 17 May 2010 at 12:13

• Changed state: Fixed

[GoogleCodeExporter]

Yes, I think ss is quite useful, especially for computing/logic intensive 
programs. 
In such programs, dynamic language features are less used. 
Most features are common in both C++ and python, for example object 
based/oriented, 
namespace, constructor, polymorphism... It's not hard to understand the
philosophy and basic mechenism to translate into C++ for native compilation. I 
believe SS can fill the gap between python's productivity and C++'s runtime 
efficiency.

Marvellous!!!

Thanks
Jason

Original comment by jason.mi...@gmail.com on 17 May 2010 at 1:29