Hi Volker,
On 2013-08-22, Volker Braun <[email protected]> wrote:
> I don't really like the way to express the condition in
> @conditionally_defined, it breaks the Python idiom of explicitly passing
> self. Whats the advantage of
>
> @conditionally_defined('cond')
> def foo(self)
> return ...
>
> over
>
> def foo(self):
> if self.cond: return super(Class, self).foo()
> return ...
The former checks the condition exactly once per instance. The latter does
the test and the super(...) call as often as foo() is called. In
particular, if the condition is nontrivial to compute, it would be quite
noticeable.
With the latter idiom, it would be difficult to obtain that self.foo is
cached if and *only* if the condition holds. Namely, doing
@cached_method
def foo(self):
if not self.cond: return super(Class, self).foo()
return ...
would mean: self.foo() is cached even if the condition does not hold and
super(Class, self).foo() is not cached. But doing
@conditionally_defined(lambda x: x.cond)
@cached_method
def foo(self):
return ...
would mean: self.foo() is only a cached method if self.cond holds,
otherwise super(Class, self).foo() is called (without being cached).
Anyway, I guess Nicolas can tell more about its uses in MuPad.
Cheers,
Simon
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
