#12978: conditionally_defined decorator for methods and other attributes
-------------------------------------------------+-------------------------
Reporter: nthiery | Owner: jason
Type: enhancement | Status: new
Priority: major | Milestone: sage-
Component: misc | wishlist
Keywords: categories, | Resolution:
conditionally_defined | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: #15056 | Stopgaps:
-------------------------------------------------+-------------------------
Comment (by SimonKing):
Replying to [comment:20 nthiery]:
> Replying to [comment:18 SimonKing]:
> > > At some point, I need to find out what class the default
> > > implementation is defined for, so that one can get the non-default
> > > implementation by a call to `super`. That's a problem. Currently,
> > > I go up the class hierarchy and test whether the
> > > conditionally_defined instance is in the `__dict__` of the
> > > class. But if the conditionally_defined instance is wrapped in a
> > > different wrapper (e.g., a cached_method), then this way of
> > > determining the class will fail.
>
> I haven't looked at the code; just wondering: since ``lazy_attribute``
> is already doing something like this could this piece of work be
> delegated to it?
No, because `lazy_attribute` does not care about what is defined in the
super-class. But the `conditionally_defined` decorator ''has'' to care
about what is defined in the super-class, and thus has to know "super with
respect to WHAT class".
By the way, a simple lazy attribute would not work on special methods of
instances of `<object>`.
> The Descriptor protocol is described quite in detail in
> http://docs.python.org/2/howto/descriptor.html; maybe it says
> something about this.
Thank you, I'll have a look
>
> By the way: the
> {{{
> @cached_method
> @conditionally_method
> ...
> }}}
> feature is nice looking for comprehensiveness, but I am really not
> sure I have a real use case for it.
No?? Well, you could of course obtain the same behaviour if you use the
@cached_method decorator ''both'' on the default implementation and the
non-default implementation:
{{{
class A(object):
@cached_method
def method1(self,...):
...
class B(A):
@conditionally_defined(...)
@cached_method
def method1(self, ...):
...
}}}
This has ''nearly'' the same effect as this:
{{{
class A(object):
def method1(self,...):
...
class B(A):
@cached_method
@conditionally_defined(...)
def method1(self, ...):
...
}}}
The difference between the two approaches is that in the second approach
the class A has a non-cached method1. And perhaps it is intended that it
does not have a cache.
> So if dropping this feature makes
> the code simpler, go for it.
{{{
@cached_method
@conditionally_defined(...)
}}}
is implemented in #15056 (which I think is useful independent of
conditionally_defined).
{{{
@conditionally_defined(...)
@cached_method
}}}
is implemented here, and it does not pose an additional complication: We
want (under a certain condition) to bind a method to an instance, and
that's the same as binding a `CachedMethodCaller` to the instance.
--
Ticket URL: <http://trac.sagemath.org/ticket/12978#comment:22>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" 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-trac.
For more options, visit https://groups.google.com/groups/opt_out.
