Dear All,
sorry for the late reply and thank you very much for the input.
As far as having methods not always defined the consensus here is leaning
towards making sublcasses but I am quite reluctant to do that because of
future things I want to implement. Down the road there are going to be many
more methods that only make sense in certain cases and not in others.
Unfortunately the cases are many so that I would have to implement lots of
different classes. The sublclass approach is the OOP-clean way but it can be
nightmarish to maintain if there are too many corner cases. This will be one
such situation when everything is implemented.
Johan's suggestion is very intriguing but, unless I am completely mistaken,
it does not work in python. If I understand correctly if O is an instance of
Foo and O does not have the attribute x then python looks for Foo().x
At the moment it seems "better" (sigh) to define the methods anyway and raise
an error in case they are meaningless. Any objection?
As for the question about the wrapper. Currently I am using @wrap and not
@sage_wrap but the result is analogous. I am indeed changing the
documentation at decoration-time (that is what I meant by "on the fly") and
reviewers are objecting precisely to this.
Could someone explain to me how sublcasses can help here?
Could you please have a look at the code? The branch is
public/ticket/21254. The wrapper begins at line 358 and the documentation
edit at line 384. The methods being wrapped are at lines 1047 and 2150.
Thanks
S.
* Johan S. H. Rosenkilde <maill...@atuin.dk> [2016-11-07 09:45:57]:
VulK writes:
The first question is about which is the correct way to implement methods
that are not always defined.
I agree with Nils that subclassing is the most OOP-clean way of
achieving this. That being said, one might argue that it is a pretty
heavy-handed solution which potentially leads to class-explosion and
mega-multiple-inheritance.
Another possibility is to do the converse of what you are doing: add the
method on the class but *delete* at construction time if it is not
appropriate. This can be done using delattr.
VulK writes:
The second problem is a little more involved, I will try to give you a souped
up version here.
...
Did you take a look at performing the preparsing using a decorator which
properly uses @sage_wraps? It is possible to do the documentation
modification at decoration-time, and then it should properly show up in
Sphinx as well.
Best,
Johan
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
