Yury V. Zaytsev added the comment:
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 .
--
nosy: +zaytsev
___
Python
Mark Dickinson added the comment:
I created http://projects.scipy.org/numpy/ticket/2235 to track this. Closing
this issue.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5476
Serhiy Storchaka added the comment:
It is more than 6 months old with no activity.
--
nosy: +serhiy.storchaka
status: pending - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5476
___
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5476
___
___
Python-bugs-list
Amaury Forgeot d'Arc added the comment:
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
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Travis, feel free to close this without further action or use the information
here to open a numpy issue.
--
assignee: belopolsky - teoliphant
status: open - pending
___
Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
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
Terry J. Reedy tjre...@udel.edu added the comment:
Inconsistent headers ;-)
Should this be closed as invalid and superceded,
or open without resolution?
I cannot tell from discussion; one of you please choose.
--
nosy: +terry.reedy
versions: -Python 2.5, Python 2.6
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
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.
--
Terry J. Reedy tjre...@udel.edu added the comment:
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
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
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
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
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__ (123)
0
class
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
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()?
--
nosy: +amaury.forgeotdarc
status: pending - open
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
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; \
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
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
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
assignee: - belopolsky
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5476
___
engelbert gruber grub...@users.sourceforge.net added the comment:
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
New submission from Barron Henderson barr...@gmail.com:
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
Changes by Barron Henderson barr...@gmail.com:
--
components: +Library (Lib)
versions: +Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5476
___
David W. Lambert lamber...@corning.com added the comment:
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,
20 matches
Mail list logo
