On 10/31/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > Please read my posts about the Python type-object verses normal Python > Object situation. That really is the crux of the matter. > I read the whole python-dev thread before replying. I may be a little biased because I never liked somewhat cryptic letter codes in Numeric and the change of codes from Numeric to numpy did not contribute to my sympathy particularly when the convert script changed all unrelated instances of 'b' in my code to something else. I am also not a big fan of record arrays. I believe that numeric data should be stored in "inverted tables," where columns of homogeneous data are stored contiguously. With this disclaimer, I will address a few issues below.
> Ctypes uses a Python type object for every data-format. > NumPy uses an instance of a data-type object for every data-format. > Yes, but AFAIK this is a recent innovation. Numarray used type objects and Numeric simply used letter codes. > What advantage do we gain by making every instance of a data-type object > *also* a Python type object? I think the main advantage is that you can have instances: >>> c_int(42) c_int(42) Of course, numpy has scalars for that, but ctypes also has fixed-length arrays, that are somewhat different from ndarrays: >>> a10 = c_int*10 >>> a10() <__main__.c_int_Array_10 object at 0x2a95816958> > We get a lot of head-ache. Have you seen > what ctypes had to do? It had to define a new Dictionary object so it > could attach it to the tp_dict parameter because you can't just inherit > from the PyTypeObject and add the fields you want to the structure. > This is my argument. > But, isn't this someone else's head-ache? Someone has already gone through all these contortions, why not reuse the effort? Others on python-dev described some specific needs of ctypes that your datatype object does not address. Your point seems to be that numpy does not share these needs and could use a much simpler approach. > I for one am not going to put any effort in that direction. People are > free to do it, if they want, of course. But, it's no small change. Can you present some use cases that illustrate the advantage of your datatype approach best? I will try to implement them with ctypes. > I would, however, put effort into "undertstanding ctypes objects" as > data-type objects. Yes, this is the key. I think we should better understand ctypes limitations before proposing an alternative. At the end of the day, it is better to have buffer protocol that describes the data using ctypes types than to have no standard type information at all. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion