On 14 Mai, 20:56, Ronan Lamy <[email protected]> wrote: > I'm not sure what you mean about "routines that cannot be abstract", but > if you're saying that it doesn't really make sense for a subclass of > Matrix to have, for instance, dict manipulation methods, I tend to > agree. The data structures should probably be attributes of the matrix > class, rather than be the matrix class itself. So we should have: > > class DOKMatrix(...): > def __init__(self, key_dict, ...): > self.dok = DOK(key_dict) > ... > > def __iadd__(self, other): > ... > self.dok.update(other.dok) > ... > > but not this: > > def _update(self, dic): > self.dok.update(dic)
I agree. > If it's only for internal use, then it's not an interface. I guess we have a different understanding of "interface". Code for "internal use only" has to interact with other (internal) parts as well. And interaction implies an interface in my understanding, even if it is not "public". So I think the point where we don't agree is the lowest level. You think the "internal" code shouldn't be procedural. I'm not convinced that OO is easier to read/maintain/develop at the lowest level, when implementing linear algebra algorithms. > And if it's > meant to be used from the outside, then it should be designed as such. It is meant to be used from the inside, and only from the outside if you care a lot about performance. > The purpose of a low-level interface is to abstract away details that > happen at a lower level. I think at the lowest level it is rather code reuse than abstraction. > So if you have an operation that combines data > structures in some specified ways, you should be able to call a single > function or method to do it, and it will take care of whatever tedious > bookkeeping is required. What to you mean with tedious bookkeeping? Remembering which arguments to pass for example? Vinzent -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
