From: Todd M. <jm...@st...> - 2003-01-27 19:53:01
|
Francesc Alted wrote: >A Dilluns 27 Gener 2003 17:28, Todd Miller va escriure: > > >>>So, as numarray has to work with previous python versions, there is no >>>point to care about that. >>> >>> >>In truth, numarray-0.4 and up already require Python-2.2 and up. >> >> > >Oh!, I didn't know that. In such a case, I think it's worth to consider the >possibility to define records as classes descendants from metaclasses. But, >of course, you have the ultimate decision. > > I don't know what you mean here. Please spell it out a little more. > > >>>>I'm thinking the general format for this may be converting N-tuples of >>>>types and ints into N arrays of types and ints. And vice versa. >>>>It's obvious how this works with numarray types. I think the chararray >>>>types need work and need to be mapped into the same integer enumeration >>>>as the numeric types in a non-overlapping way. >>>> >>>> >>>I can't catch your point here. Why there should be a problem with >>>chararrays?. >>> >>> >>What I was trying to see is that chararray types are not as well >>designed as the numarray types, nor are they reflected in the C-API. >> >> > >I see. Well, is it really desirable such a unification? CharArray entities >come from a module and NumArray from another one, and that should be ok. Why >bother in creating a unified API or integer enumeration?. > It may not be necessary. Int8 with repitition factors may work about the same. |