Initializing a timedelta object with numpy.int32 arguments give mixed
results; it fails for days keyword, gives bad results for minutes, and
give correct results for seconds/microseconds.  Failure confirmed on
Linux i686 (Py 2.5.2; numpy 1.2.1) and OS X 10.5.6 (Py 2.5.1;
1.2.1).Test case below:

from datetime import timedelta
from numpy import int32
from numpy import int32
from datetime import timedelta

assert timedelta(seconds = 36) == timedelta(seconds = int32(36))
print 'pass 36 sec'
assert timedelta(microseconds = 36) == timedelta(microseconds = int32(36))
print 'pass 36 usec'
assert timedelta(minutes = 35) == timedelta(minutes = int32(35))
print 'pass 35 min'
assert timedelta(minutes = 36) == timedelta(minutes = int32(36))
print 'pass 36 min' # returns bad value
assert timedelta(days = 36) == timedelta(days = int32(36))
print 'pass 36 days' # fails SystemError: Objects/longobject.c:223

With older versions of each timedelta rejects the data type.  Maybe
that's a good resolution?

$ /usr/local/bin/python2.4 
Python 2.4.2 (#2, Jul  7 2006, 10:20:47) 
[GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.version.version
'0.9.8'
>>> from numpy import int32
>>> from datetime import timedelta
>>> assert timedelta(seconds = 36) == timedelta(seconds = int32(36))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported type for timedelta seconds component: int32scalar
>>>

testing with 2.6 and numpy 1.3 already ::

   timedelta(seconds = int32(36)) 
   TypeError: unsupported type for timedelta seconds component: 
numpy.int32

But not if I apply a change to numpy to fix issue2263
then ``timedelta(days = int32(36))`` and ``timedelta(minutes = 
int32(36))`` result in wrong timedeltas.

This is a bit strange.  timedelta is accepting int subclass instances:


>>> class I(int):
...    pass
... 
>>> timedelta(days = I(36))
datetime.timedelta(36)


but not numpy.unt_:


>>> timedelta(days = int_(36))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported type for timedelta days component: numpy.int64

which is also a subclass of int:

>>> isinstance(int_(36), int)
True

This is probably a numpy quirk rather than python issue, but is probably worth another look.

As I suspected, datetime not recognizing numpy.int_ as a valid input is a numpy issue.  Unlike regular int subclasses, numpy.int_ does not have Py_TPFLAGS_INT_SUBCLASS flag set:


>>> numpy.int_.__flags__ & (1<<23)
0

>>> class foo(int): pass
... 
>>> foo.__flags__ & (1<<23)
8388608

What python can improve in this area is documentation.  See issue9307.

Py_TPFLAGS_INT_SUBCLASS is an implementation detail, and extension modules should not have to be aware of it.
Does Numpy correctly call PyType_Ready()?

> Does Numpy correctly call PyType_Ready()?

As far as I can tell, it does:


#define DUAL_INHERIT(child, parent1, parent2)                           \
    Py##child##ArrType_Type.tp_base = &Py##parent2##ArrType_Type;       \
    Py##child##ArrType_Type.tp_bases =                                  \
        Py_BuildValue("(OO)", &Py##parent2##ArrType_Type,               \
                      &Py##parent1##_Type);                             \
    if (PyType_Ready(&Py##child##ArrType_Type) < 0) {                   \
        PyErr_Print();                                                  \
        PyErr_Format(PyExc_SystemError,                                 \
                     "could not initialize Py%sArrType_Type",           \
                     #child);                                           \
        return -1;                                                      \
    }                                                                   \
    Py##child##ArrType_Type.tp_hash = Py##parent1##_Type.tp_hash;
    ...
    DUAL_INHERIT(Int, Int, SignedInteger);

Could it be the multiple inheritance that causes the problem here?

multiple inheritance should not be a problem: there can be only one "dominant base", which is 'int' in this case.
someone with a debugger should step into this call to PyType_Ready() and see why it does not set the flag correctly (at the end of inherit_special())

Inconsistent headers ;-)
Should this be closed as invalid and superceded,
or open without resolution?
I cannot tell from discussion; one of you please choose.

This is clearly an invalid issue for python, but I wanted to keep it open until I or someone else gets a chance to report it to numpy project.  I was hoping to close this with a link to numpy tracker.

A link can be added at any time. Closing does nothing except remove an issue from searches of open issues. Please close this or allow me to. There is a cost to keeping things like this open -- the puzzlement of anyone reading it and the time cost to triage maintainers like me ;-)

Terry,

Realistically, though, if you close this issue it is virtually guaranteed that not further action will be taken.  I have not been involved with numpy for a couple of years now, so it would take me some time to find their tracker and restore my credentials or open a new account.  If someone more familiar with the current numpy development comes across this issue, I would appreciate if he or she would make a report.

If you think keeping this issue open in this state is too much burden on triagers, feel free to close it.  IMO, however, triagers should ignore assigned issue unless they are more than say 6 months old with no activity.

Travis, feel free to close this without further action or use the information here to open a numpy issue.

It is more than 6 months old with no activity.

From the macro posted earlier:
  Py##child##ArrType_Type.tp_base = &Py##parent2##ArrType_Type;

tp_base is *not* PyInt_Type, so I was wrong when I said that the dominant base was int.
This is wrong IMO: tp_base should be int, for the type to be correctly initialized.

Compare:
>>> from numpy import *
>>> print int_.__bases__, int_.__base__
(<type 'numpy.signedinteger'>, <type 'int'>) <type 'numpy.signedinteger'>
>>> class C(signedinteger, int):
...     pass
... 
>>> print C.__bases__, C.__base__
(<type 'numpy.signedinteger'>, <type 'int'>) <type 'int'>

I created http://projects.scipy.org/numpy/ticket/2235 to track this.  Closing this issue.

NumPy no longer uses the Trac for issues, the tracking has been moved to GitHub. I hope that the problem will be finally solved in NumPy by https://github.com/numpy/numpy/pull/3526 .