It seems to me that at the python level, there's not much reason to choose the dtypes proposal over ctypes.
I disagree. I can see a point in unifying ctypes and dtypes but in my
mindset they've got two different scopes.
ctypes is an interface to the c language
dtype is a data description for the python language
The biggest advantages python has over c in my mind (except the script
vs compile) is that it's dynamic and expressive. I think basing dtype
on ctypes is in that mind is simply destructive and against what I
like best with python.
ctypes mimics c's static behaviour:
class struct_type(Structure):
_fields_ = [....]
...
... which is somewhat static in nature. How do you create "structures"
dynamically?
How do you do things like this in ctypes:
mytype=filter(lambda x: is_little_endian(x),map(lambda x: x==int32 and
int64 or x, old_type))
b=['gg',[1,2,3]]
mytype=dtype([{str: uint64 , list:another_type }[type(x)] for x in b])
I'm sure it's possibl but I'm also suspecting it not at all as clean
and expressive (my second argument for choosing python over c).
Since we creating something new in python isn't it best we do
something the python way and later see if we can adapt the c structure
to that rather than the other way around? If we can't adapt ctypes to
this new thing i'm perfectly happy with leaving ctypes as is.
ctype is doing a great job on the c interaction level but is plain
ugly on the python level.
On 11/1/06, Bill Baxter
On 11/2/06, A. M. Archibald
wrote: On 01/11/06, Travis Oliphant
wrote: And it may be a good idea to also have a get_ctype method or some-such on the ctypes attribute so that one could get a "ctypes description" from the NumPy data-type.
It seems to me that at the python level, there's not much reason to choose the dtypes proposal over ctypes. There is one at the C level, it seems (though I, like perhaps most of the people on python-dev, have never actually tried using either). So perhaps, to persuade the python-dev folks, what is needed is a comparison of what has to be done at the C level. What would it take to rewrite numpy to use ctypes? There seems to be some problem with extending the type objects used by ctypes, but it's not very clear to me what that problem is (what the extensions are supposed to do).
I posted a message to the thread trying to prod things in that direction. I.e. can we see a simple concrete example of the complications involved in using ctypes interface code, vs the presumably much nicer numpy/data-descriptor code. I too think that would help convince people. Just saying it's more compilcated, trust me, doesn't help when most people reading the list have never had to write any sort of C extension.
--bb
------------------------------------------------------------------------- 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
------------------------------------------------------------------------- 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