Friedrich Romstedt wrote: > 2010/9/23 Dag Sverre Seljebotn <da...@student.matnat.uio.no>: > >> Essentially, perhaps what you have sketched up + an ability to extend >> the graph with object conversion routes would be perfect for my own >> uses. So you can define a function with overloads (A, B) and (A, C), but >> also that objects of type D can be converted to C (and how). For >> instance, consider: >> >> np.array([1,2,3]) + [1,2,3] >> >> Here, list-> array could be handled through a defined coercion to array, >> rather than having to add an overload for list for every method taking >> an array. >> > > This seems to be a good thing. Let's reason about this for some > moment. Atm, the relation is *not* transitive. (I.e., (A, B) and (B, > C) does imply nothing for (A, C). A, B, C classes.) But such kind of > transitivity is what you mean, if (A, B) is defined and there is a > graph egde in the "conversion graph" (B, C), then (A, C) can choose > the (A, B) route via C -> B conversion; here the notation (B, C) in > the conversion graph means "conversion from C to B". > > I don't see a clear solution at the end satisfying me. It seems that > one really has to conduct a search in the additional conversion graph. > Since this is expensive, I believe it would probably be good to > derive a "ConversionPriop" from priop.Priop. > > What are your thoughts now? >
You can just cache all lookups in the conversion graph, so that after some initialization all lookups are O(1). There's a limited number of types in a Python runtime, and the actual distinct lookups performed are likely to not be many. I don't see that as a problem at all. I'll try to remember to get back to the rest in a week or so...I'm handing in my MSc on Thursday :-) Dag Sverre _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion