On Thursday, May 15, 2014 12:11:31 AM UTC-7, Nathann Cohen wrote:
>
> I would accept the argument of "speed issue", but of course you cannot use 
> that one AND defend the "key" parameter, which has an easier workaround 
> than my problem here and a higher cost. So it is both or none, see ? :-P
>

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. 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.

The justification is also a little different: "key" doesn't change the 
logical operation of the cache. It just provides a way to customize the 
normalization of the arguments (which always happens and I think people 
underestimate in how costly it can be: arguments to python function can 
look awfully complicated and to normalize them in a way that reflects how 
python binds them is a lot of work). I some doubts about its current 
implementation. Perhaps it should really just provide an *alternative* to 
the default argument_fixer.fix_to_pos. Especially the line

return self.key(*args, **dict(kwargs))

worries me a bit. (here `kwargs` is an already processed version of an 
incoming `**kwargs`!). I suspect that if this ever turns out to be a widely 
used feature, we'll have to have some changes that are incompatible in edge 
cases to arrive at a cleaner/more efficient design.

-- 
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.

Reply via email to