On Fri, Sep 27, 2013 at 1:40 PM, Gary Martin <[email protected]>wrote:
> 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). >> >> PS: Notice that in my initial message I stated "If .* with no further changes" 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.) > > Gary's suggestion is quite interesting . We could move the code in lookup_env into a decorator meant to wrap meta-class __call__ method . I'm fond of uniformity and , if cache semantics and consistency are not compromised then I'd be ok with improvements . -- Regards, Olemis - @olemislc
