Yoooooooo !! > It's a potentially valid point that the introduction of the "key" parameter > might have affected normal operation, but I just checked: it does not.
Hmmmm... I first thought that fix_to_pos was part of this "key" stuff, but you seem to consider it something different. My thoughts were "Okay, clearly this normalization is applied at every call, and what I do is only a "if" applied when __call__ is called on a non-cached value, so it has to be cheaper !". If you don't count the "if" that triggers this normalization then it does not stand anymore, and it looks like you have to apply this "if" anyway because you cannot store a dictionary as a key of another dictionary. Hmmmm... > At initialization time (i.e., when the decorator creates the wrapping > object), the presence of the key argument is checked and if it's not there, > the exact old code is executed, so if key is not there, it is guaranteed to > not affect runtime performance in any way. *deciding* whether something needs > to be cached will always be a runtime decision. Well, changing the key that is used to cache it is also a runtime decision.... But it does not seem to add any "if" in the general case indeed. What worries me is that I will have to add a lot of dirty and totally unrelated stuff to combinat/designs/ to get the behaviour I want T_T Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
