> > 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 <[EMAIL PROTECTED]> wrote:
>
> On 11/2/06, A. M. Archibald <[EMAIL PROTECTED]> wrote:
> > On 01/11/06, Travis Oliphant <[EMAIL PROTECTED]> 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
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
