Simplification is always a wise thing. How about thinking ahead and already anticipate the times when Numeric and numarray fade away and are slowly replaced by numpy? It is the clear goal of all developers involved to make the two old libraries obsolete as fast as possible. They will probably hang around for some time for legacy projects, but nobody should expect to be able to update their legacy project to the bleeding edge pytables while still using either numarray or Numeric.
That is: I do not suggest to drop support for these packages now or anytime in the near future, but when doing design decisions that call for major redesign, this should already be considered: If Numeric and numarray didn't exist, the whole concept of flavors could be dropped completely. PyTables would simply depend on NumPy and every object would be either a NumPy object or a native Python object. I don't know enough about the internals of PyTables to say how one would best implement an intermediate solution, but it should clearly aim at the ultimate goal of full numpy unification. Greetings, Norbert Francesc Altet wrote: >Hi, > >During my implementation of support for numpy in PyTables, I've >concluded that the current support for object flavor (you know, the >additional conversion that can automatically make PyTables from native >numarray objects to other objects) is getting a bit messy. > >Hereby is a proposal for reducing the number of different flavors in >PyTables to a bare minimum. > >Current FLAVOR values: > >"NumArray" - Homogeneous numerical numarray objects >"CharArray" - Multidimensional strings numarray objects >"Numeric" - Numeric object >"List" - Python list of objects >"Tuple" - Python tuple of objects >"String" - Python string >"Int" - Python integer >"Float" - Python float > >Proposed FLAVOR values: > >"numarray" - All kind of numarray objects, i.e. homog., heter., strings >"numpy" - All kind of numpy objects, i.e. homog., heter., strings >"numeric" - Homogeneous Numeric objects >"python" - Python objects (list or scalars) > >I think that this simplification can be made because the metadata >about the objects on disk can inform about what kind of data they are >(scalar/multidimensional, character-based, homogeneous/heterogeneous) >so, in the end, with just the four of aforementioned flavors would be >more than enough to deal with the different object conversions. > >If I get no objections/suggestions on the new schema, I'll proceed to >implement it right now and update the documentation accordingly. This >will imply that if any of you are making extensive use of the flavor >mechanism, then chances are that you should update your source files. >This is the price to pay for the simplification. I'll try, however, to >make the change as backward compatible as possible, so that files with >old values of flavors can properly be read in the new version of >PyTables. > >Cheers, > > > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Pytables-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pytables-users
