bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: ProductEnvironment constructor
Date Fri, 27 Sep 2013 18:55:53 GMT
On Fri, Sep 27, 2013 at 1:40 PM, Gary Martin <gary.martin@wandisco.com>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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message