> >-----Original Message----- > >From: Michael Tobis [mailto:[EMAIL PROTECTED] > > > >You can present the identical API with a wrapper as with a > >native extension, and stay out of the mathematician's way > >altogether, no? If not, why not?
Well, instead of arguing what is not optimum about the solution that I *think* you are suggesting I will argue what is - only because I think it brings me around in full circle - I *think* - to where I started. The wrapper allows me to maintain object identity when working within complex typed Numeric arrays, since it is an object attribute been sent and received from the arrays, not the object itself. The solution that I have been exploring is more fragile in this respect. Since Numeric will not accept my complex object as such, and I need to cast it to a complex built-in on the way into the array and back to a complex custom type on the way. My object identity is lost. This is not a killer under my present structure, but is certainly has a more fragile feel that I would like. But in my mind it is only because in moving into Numeric land I am moving out of a land of duck typing and into a land of strict typing. Its Numeric's fault, not mine ;). I was hoping for some elegant solution to this particular issue that is not obvious to me. The other answer is that I should not attempt to fight Mother Nature in this regard. Art _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
