<br><br><div class="gmail_quote">On Thu, Jun 11, 2009 at 10:29 AM, Travis Oliphant <span dir="ltr"><<a href="mailto:oliphant@enthought.com">oliphant@enthought.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><br><div><div><div></div><div class="h5"><div>On Jun 10, 2009, at 11:18 PM, Charles R Harris wrote:</div><br><blockquote type="cite">Hi Travis,<br><br>I looked through the recent commits to the datetime branch and, as I'm working on cleaning up arraytypes I would appreciate it if you can merge up your changes there as soon as possible to minimize conflicts. Also, this change looks like a reversion of current trunk to something older:<br>
 <br><pre style="display: block; font-family: courier new,monospace;">@@ -2688,10 +2690,8 @@<br>         goto err;<br>     }<br>-    /*<br>-     * PyExc_Exception should catch all the standard errors that are<br>-     * now raised instead of the string exception "multiarray.error".<br>

-     * This is for backward compatibility with existing code.<br>-     */<br>-    PyDict_SetItemString (d, "error", PyExc_Exception);<br>+    /* Fixme: we might want to remove this old string exception string */<br>

+    s = PyString_FromString("multiarray.error");<br>+    PyDict_SetItemString (d, "error", s);<br>+    Py_DECREF(s);<br>     s = PyString_FromString("3.0");<br>     PyDict_SetItemString(d, "__version__", s);</pre>
 And I am concerned that there might be other such cases.</blockquote><div><br></div></div></div>There may be.    I took Robert's git branch and tried to re-base it.  But, I'm a git neophyte and didn't know what I was doing.   I tried to eliminate the most obvious cases where is trunk was out-of-date, but obviously missed some.  </div>
<div><br></div><div>Thanks for checking.  I don't want to stomp on your work, but I don't know what you mean by cleaning up arraytypes? </div><div></div></div></blockquote><div><br>Oh, and slipping the new types in between 64 bit integers and floats is a bit iffy. I've always been a bit bothered by numpy's dependence on the linear order of the types as it is hard to maintain when new types are added, and user types don't seem quite adequate. I don't know what we should do here but it might be worth thinking about some other way of indicating the relation/priority of the different types.<br>
<br>Chuck  <br></div><br></div><br>