pygccxml-development

[pygccxml-development] recursive import trick

[Allen B. <al...@vr...>]

I was just trying to trace through the code in declarations.scopdef and 
I ran across a comment in declrations._init_.py about needing to use a 
rather interesting set of dictionaries in scopdef_t to inject some types 
for use when looking up matchers.

There is a comment on line 223 saying this is to prevent recursive 
imports, but it doesn't go into details about what imports cause this 
issue.  Could anyone shed some light on this?

-Allen

Re: [pygccxml-development] recursive import trick

[Roman Y. <rom...@gm...>]

On 7/26/06, Allen Bierbaum <al...@vr...> wrote:
> I was just trying to trace through the code in declarations.scopdef and
> I ran across a comment in declrations._init_.py about needing to use a
> rather interesting set of dictionaries in scopdef_t to inject some types
> for use when looking up matchers.
>
> There is a comment on line 223 saying this is to prevent recursive
> imports, but it doesn't go into details about what imports cause this
> issue.  Could anyone shed some light on this?

In order to improve performance scopedef_t class instance contains few
dictionaries:
_type2decls, _type2name2decls, _type2decls_nr, _type2name2decls_nr.
( nr = none recursive )

Now, in order to build all those dict, it needs to know all
declarations types. This inlcudes
namespace_t and class_t. But scopedef_t is a base class for those classes.
So, I added 2 new class variables:
    _impl_all_decl_types -  this is a list of all declaration classes
    _impl_decl_types - this is a dict that maps between scopedef_t
select method and
                                declaration class.

Did my explanation help?

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] recursive import trick

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

> On 7/26/06, Allen Bierbaum <al...@vr...> wrote:
>
>> I was just trying to trace through the code in declarations.scopdef and
>> I ran across a comment in declrations._init_.py about needing to use a
>> rather interesting set of dictionaries in scopdef_t to inject some types
>> for use when looking up matchers.
>>
>> There is a comment on line 223 saying this is to prevent recursive
>> imports, but it doesn't go into details about what imports cause this
>> issue.  Could anyone shed some light on this?
>
>
> In order to improve performance scopedef_t class instance contains few
> dictionaries:
> _type2decls, _type2name2decls, _type2decls_nr, _type2name2decls_nr.
> ( nr = none recursive )
>
> Now, in order to build all those dict, it needs to know all
> declarations types. This inlcudes
> namespace_t and class_t. But scopedef_t is a base class for those 
> classes.
> So, I added 2 new class variables:
>    _impl_all_decl_types -  this is a list of all declaration classes
>    _impl_decl_types - this is a dict that maps between scopedef_t
> select method and
>                                declaration class.
>
> Did my explanation help?
>
The explaination helped.  I am still a little confused though.  How did 
this problem manifest? 

It would seem that if we have:

scope_def_t:
import namespace_t

namespace_t:
import scope_def_t

Then importing namespace_t should be fine from user code as long as 
scope_def_t doesn't use namespace_t in the module/global scope. 

Assuming you are interested in removing this hack, there may be some 
ways around this cycle though, what I can think of right now is:
- import the derived types only in the course of executing the 
optimization methods.  This would delay the import until scope_def_t is 
fully defined.
- Just move all the optimization code to a helper class that scope_def_t 
uses if optimizations are enabled.

Personally I like the second option because I find the scope_def_t 
implementations to be a little hard to understand because of the 
optimization code that is in each method.

-Allen

Re: [pygccxml-development] recursive import trick

[Roman Y. <rom...@gm...>]

On 7/26/06, Allen Bierbaum <al...@vr...> wrote:
> The explaination helped.  I am still a little confused though.  How did
> this problem manifest?
>
> It would seem that if we have:
>
> scope_def_t:
> import namespace_t
>
> namespace_t:
> import scope_def_t
>
> Then importing namespace_t should be fine from user code as long as
> scope_def_t doesn't use namespace_t in the module/global scope.

The problem is not in the user space. I did not filled comfortable to
import namespace.py and class.py from scopedef.py.

> Assuming you are interested in removing this hack,

Yes, I am. I am glad you raised this problem.

> there may be some
> ways around this cycle though, what I can think of right now is:
> - import the derived types only in the course of executing the
> optimization methods.  This would delay the import until scope_def_t is
> fully defined.

I have mental problem with this solution :-).

> - Just move all the optimization code to a helper class that scope_def_t
> uses if optimizations are enabled.
>
> Personally I like the second option because I find the scope_def_t
> implementations to be a little hard to understand because of the
> optimization code that is in each method.

And I agree with you. If I remember right, I thought about this solution, but
for some reason, decided not to implement it. Definitely I will have
to reconsider
my decision.

I am not going to change this before next release. This change is too big.
And I still need to implement 2 features + documentation. Sorry.
May be you can prepare patch? I will apply it after release.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/