[Numpy-discussion] datetime uses API deprecated in python3.1

[Charles R Harris]

On Mon, Feb 22, 2010 at 1:03 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Mon, Feb 22, 2010 at 12:26 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>>
>> On Sun, Feb 21, 2010 at 6:48 PM, Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>>
>>>
>>> On Sun, Feb 21, 2010 at 11:34 AM, Pauli Virtanen <pav at iki.fi> wrote:
>>>
>>>> su, 2010-02-21 kello 20:17 +0200, Pauli Virtanen kirjoitti:
>>>> [clip]
>>>> > The Capsule API seems pretty much the same as the CObject API. (Why
>>>> the
>>>> > name change?) We can probably #define PyCapsule_* compatibility
>>>> defines
>>>> > in npy_3kcompat.h that use PyCObject on 2.x, and use the real thing on
>>>> > 3.x.
>>>>
>>>> Btw, I read that PyCObjects are completely gone on Python 3.2, so
>>>> apparently we *have* to make this transition.
>>>>
>>>>
>>> It does look like the old interface can be emulated with the new objects,
>>> but the need for a 'name' might cause trouble. I suppose that will depend on
>>> how the current objects are used.
>>>
>>>
>> List of files containing string PyCObject
>>
>> numpy/numarray/include/numpy/libnumarray.h
>> numpy/numarray/_capi.c
>> numpy/core/include/numpy/ndarrayobject.h
>> numpy/core/src/multiarray/common.c
>> numpy/core/src/multiarray/descriptor.c
>> numpy/core/src/multiarray/multiarraymodule.c
>> numpy/core/src/multiarray/getset.c
>> numpy/core/src/multiarray/convert_datatype.c
>> numpy/core/src/multiarray/arraytypes.c.src
>> numpy/core/src/multiarray/scalartypes.c.src
>> numpy/core/src/multiarray/scalarapi-merge.c
>> numpy/core/src/multiarray/ctors.c.save
>> numpy/core/src/multiarray/usertypes.c
>> numpy/core/src/multiarray/scalarapi.c
>> numpy/core/src/multiarray/ctors.c
>> numpy/core/src/umath/ufunc_object.c
>> numpy/core/src/umath/umathmodule.c.src
>> numpy/core/code_generators/generate_numpy_api.py
>> numpy/core/code_generators/generate_ufunc_api.py
>> numpy/lib/type_check.py
>> numpy/random/mtrand/Python.pxi
>> numpy/f2py/src/fortranobject.c
>> numpy/f2py/cb_rules.py
>> numpy/f2py/rules.py
>> numpy/f2py/cfuncs.py
>>
>> It looks like context is the new name for desc, so that
>> PyCObject_FromVoidPtrAndDesc can be implemented as two calls.
>>
>> I think it is a bit tricky to implement these as macros, getting the
>> return back from a multi call substitution can be doable with a comma
>> expression, but I think a better route is to define our own library of
>> compatible functions, prepending npy_ to the current PyCObject functions.
>>
>>
> But the destructor callbacks will differ:
>
> static void
> PyCObject_dealloc(PyCObject *self)
> {
>     if (self->destructor) {
>         if(self->desc)
>             ((destructor2)(self->destructor))(self->cobject, self->desc);
>         else
>             (self->destructor)(self->cobject);
>     }
>     PyObject_DEL(self);
> }
>
> The PyCapsule callbacks only have the one argument form.
>
> static void
> capsule_dealloc(PyObject *o)
> {
>     PyCapsule *capsule = (PyCapsule *)o;
>     if (capsule->destructor) {
>         capsule->destructor(o);
>     }
>     PyObject_DEL(o);
> }
>
> There are two places where numpy uses a desc. So I think we will have to
> have different destructors for py2k and py3k.
>
>
So, I think it isn't a big problem to do this with #ifdef's in the code.
That is the way I'm going unless you object. I'm not sure if using PyCapsule
objects will make pickled arrays incompatible between py2k and py3k, but so
it goes.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100222/fff5d386/attachment.html>