bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: ProductEnvironment constructor
Date Fri, 27 Sep 2013 18:40:28 GMT
On 27/09/13 17:55, Anze Staric wrote:
>> ... that's not the only reason . By reviewing meta-class code you'll
>> notice that instances of ProductEnvironment are cached considering
>> initializer input parameters i.e. global env + prefix . That been said
>> this is how I see it
> That lru_cache already uses a custom keymap, we would just have to
> modify it to cache on the right values (the same way it uses prefix
> for caching, even if Product instance is provided).
>
> But even if we do not fix it, I noticed we have
> ProductEnvironment.lookup_env classmethod, which uses parent env when
> needed. I will just use that whenever I need to get a product
> environment.

Interesting.. I don't know if there is really enough justification for 
fixing this up. Is it likely to help developers understand how to use 
the class easier and is that enough?

Anyway, if it is worth fixing, I think another alternative would be to 
swap the env for the parent env if necessary before the lru_cache is hit 
by adding a further decorator to __call__. This should also save us from 
having to modify the __init__ function itself (which I am even less sure 
of as I haven't followed the argument for how environment nesting would 
be stopped.)

Cheers,
     Gary

Mime
View raw message