By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,033 Members | 1,952 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,033 IT Pros & Developers. It's quick & easy.

Questions about remembering and caching function arguments

P: n/a
Hi all,

I have two questions about a class, which we'll call MyWrapperClass,
in a package to which I'm contributing.
1) MyWrapperClass wraps functions. Each instance has an attribute
called 'value' and a method called 'eval', which calls the wrapped
function. An instance D that depends on instances A, B and C can be
created as follows:

@mywrapperclass
def D(A, B, C):
return foo(A.value, B.value, C.value)

Now that D exists, the call D.eval() will work without any arguments
(D remembers that the arguments are A, B and C and passes their values
to foo). What is the standard terminology for such classes, and does
anyone know of a package that implements them in a nice way? (It's
easy enough to roll our own, but reading about other implementations
might give us good ideas).
2) D.eval() will frequently be called multiple times in succession
before A.value, B.value or C.value has had the chance to change. It
would be _extremely_ helpful to have D detect this situation and skip
recomputation. I'm looking for the fastest safe way to do this.
There's no restriction on what kind of object A.value, etc. are, so
unfortunately they might be mutable.

Our current solution is to have D compare A.value, B.value and C.value
to an internal cache using the 'is' operator (and put a big warning in
the docs about not changing 'value' attributes in-place). Not exactly
safe, but the speed savings over comparison with '==' will be
significant. Is this OK, bad or an abomination?

Again it would be helpful to know the terminology associated with the
behavior I'm looking for and any packages that implement it nicely.
Many thanks in advance and apologies for the long post,
Anand
Nov 12 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On Nov 12, 1:05 am, "Anand Patil" <anand.prabhakar.pa...@gmail.com>
wrote:
Hi all,

I have two questions about a class, which we'll call MyWrapperClass,
in a package to which I'm contributing.

1) MyWrapperClass wraps functions. Each instance has an attribute
called 'value' and a method called 'eval', which calls the wrapped
function. An instance D that depends on instances A, B and C can be
created as follows:

@mywrapperclass
def D(A, B, C):
return foo(A.value, B.value, C.value)

Now that D exists, the call D.eval() will work without any arguments
(D remembers that the arguments are A, B and C and passes their values
to foo). What is the standard terminology for such classes, and does
anyone know of a package that implements them in a nice way? (It's
easy enough to roll our own, but reading about other implementations
might give us good ideas).

2) D.eval() will frequently be called multiple times in succession
before A.value, B.value or C.value has had the chance to change. It
would be _extremely_ helpful to have D detect this situation and skip
recomputation. I'm looking for the fastest safe way to do this.
There's no restriction on what kind of object A.value, etc. are, so
unfortunately they might be mutable.

Our current solution is to have D compare A.value, B.value and C.value
to an internal cache using the 'is' operator (and put a big warning in
the docs about not changing 'value' attributes in-place). Not exactly
safe, but the speed savings over comparison with '==' will be
significant. Is this OK, bad or an abomination?

Again it would be helpful to know the terminology associated with the
behavior I'm looking for and any packages that implement it nicely.

Many thanks in advance and apologies for the long post,
Anand
Cells (A dataflow extension to CLOS) seems like what you want:

http://common-lisp.net/project/cells/

I think there was talk of a Python version a while back...

-- bjorn

Nov 12 '07 #2

P: n/a
thebjorn a écrit :
On Nov 12, 1:05 am, "Anand Patil" <anand.prabhakar.pa...@gmail.com>
wrote:
>Hi all,

I have two questions about a class, which we'll call MyWrapperClass,
in a package to which I'm contributing.

1) MyWrapperClass wraps functions. Each instance has an attribute
called 'value' and a method called 'eval', which calls the wrapped
function. An instance D that depends on instances A, B and C can be
created as follows:

@mywrapperclass
def D(A, B, C):
return foo(A.value, B.value, C.value)

Now that D exists, the call D.eval() will work without any arguments
(D remembers that the arguments are A, B and C and passes their values
to foo). What is the standard terminology for such classes, and does
anyone know of a package that implements them in a nice way? (It's
easy enough to roll our own, but reading about other implementations
might give us good ideas).

2) D.eval() will frequently be called multiple times in succession
before A.value, B.value or C.value has had the chance to change. It
would be _extremely_ helpful to have D detect this situation and skip
recomputation. I'm looking for the fastest safe way to do this.
There's no restriction on what kind of object A.value, etc. are, so
unfortunately they might be mutable.

Our current solution is to have D compare A.value, B.value and C.value
to an internal cache using the 'is' operator (and put a big warning in
the docs about not changing 'value' attributes in-place). Not exactly
safe, but the speed savings over comparison with '==' will be
significant. Is this OK, bad or an abomination?

Again it would be helpful to know the terminology associated with the
behavior I'm looking for and any packages that implement it nicely.

Many thanks in advance and apologies for the long post,
Anand

Cells (A dataflow extension to CLOS) seems like what you want:

http://common-lisp.net/project/cells/

I think there was talk of a Python version a while back...

-- bjorn
pycells : http://pycells.pdxcb.net/

but also trellis : http://peak.telecommunity.com/DevCenter/Trellis

Nov 12 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.