[SciPy-dev] Refactoring of csc/csr sparse matrices

Tim Leslie tim.leslie at gmail.com
Thu Jan 11 08:07:43 CST 2007


On 1/11/07, Robert Cimrman <cimrman3 at ntc.zcu.cz> wrote:
> Ed Schofield wrote:
> > On 1/11/07, Tim Leslie <tim.leslie at gmail.com> wrote:
> >> On 1/11/07, Nathan Bell <wnbell at gmail.com> wrote:
> >>> On 1/10/07, Tim Leslie <tim.leslie at gmail.com> wrote:
> >>>> The problem is that changing these names would break the current
> >>>> interface. This could be un-broken by using __getattr__/__setattr__ to
> >>>> trap all calls to rowind/colind and pass them on to 'indices'.
> >>>>
> >>>> So, the question is should we a) make no change, b) make the change
> >>>> and change the interface or c) make the change but keep the old
> >>>> interface. I'm personally in favour or c), but I'd like to hear what
> >>>> other people have to say.
> >>> Option C is fine with me.  Should deprecation warning be printed if
> >>> rowind/colind is used?
> >>>
> >> That's definitely a possible option. What do other people think?
> >
> > Yeah, well done. All that duplicate code is painful to maintain, and
> > there have sometimes been bugs fixed in one of the two classes but
> > forgotten in the other. I agree we should start with option (c), but I
> > think we should view the rowind and colind attributes as internals
> > anyway, not as part of the interface. Ideally, we should keep adding
> > more high-level methods so that accessing rowind or colind outside the
> > sparse module is rarely necessary.
>
> Good work! The rowind/colind dichotomy was bothering me a long time,
> too. +1 for c).
>
> I personally use the inner data in my FE assembling code, so I would
> like to have methods to get them, no matter their internal names, e.g.
> get_data(), get_ptr(), get_indices(), maybe with '_' to indicate that
> these are accessing 'private' data.
>

OK, it seems like a lot of positive feedback for option c), so I'll
clean up my patch to do that and check it in in the next 24 hours and
we can work out the next evolution of the interface from there.

Cheers,

Tim

> r.
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>


More information about the Scipy-dev mailing list