Fri Nov 20 00:03:09 CST 2009
> we're starting to use these tools more and more, and with the 1.4
> release coming out, we're a bit lost here... A few specific questions
> we have:
The short answer to all of the questions is that datetime is not done
yet. Robert and I worked on the underlying framework so that it
could be rolled in to the trunk without causing segfaults. I have
been trying to find time to work on the code since then and just got
some time this week. I made good progress on the code and fixed a
few bugs and added a few tests. If someone else has tests they have
written they could add that would be very helpful at this point.
I am planning to have a description of what remains to be implemented
and where the code is by the end of day tomorrow. This should
provide a roadmap of where we can go from here.
I don't think the code needs to be taken out of 1.4.0 (and in-fact I
would strongly discourage it). However, it would be appropriate to
keep the description of datetime out of the release notes until the
code can get implemented. The framework is fairly mature and I don't
see changes occurring, but there are un-implemented features at this
point. I will provide a summary tomorrow evening of what remains to
The largest body of work that needs to be done is the code to coerce
between date-time types and to and from other data-types. What works
now is that you can specify a date-time data-type and convert to and
from python date-time objects.
> - It seems the original spec that was written by Francesc with a lot
> of community feedback, whose final form (updated by Travis recently)
> was implemented differently in the final committed code.
There are a couple of enhancements in the final proposal, but
otherwise the original spec was followed. The biggest motivation for
these enhancements was to satisfy a use-case that was brought up by
the group that funded much of the development. Other changes are
more implementation details or driven by implementation.
> - Are there any tests for the current code, that will go in before 1.4
> is out? We'd like to know if we can rely on 1.4 as a dependency for
> nitime, but for that we'd like to know what the code can actually do,
> and also to have checks for what appear to be segfault problems:
I am planning to work hard on this over the next week or so. I don't
know how far I will get, but would like to push it as far as
possible. Help is appreciated.
> - From our experimenting with the code it appears that the following
> code is not accepted:
> a = np.array([0.1, 0.5, 0.9, 1.4], dtype='some form of spelling
> seconds, nothing we've tried has worked')
A bug in the code that was fixed today left seconds out.... However,
the biggest issue is that coercions are not yet implemented so I
would not expect any of this to work yet.
> - I know that the name numpy.datetime() was in the spec above
> (Francesc's NEP) but we're wondering if having this is a good idea...
I'm not in love with numpy.datetime or numpy.timedelta either. If
better names can be suggested, I'm all for it.
> - Sources of information? Docstrings and tests haven't gotten us very
> far, and googling points to the original spec as udpated by Travis:
The spec is the best resource right now beyond the code. i have
worked to keep the spec consistent with what is in (or will be in) the
code. However, as mentioned, it is not finished.
> But even the examples in that document don't actually work. All of
> these copied from the spec, and run with:
Again, the NEP has not been fully implemented yet. What is
implemented works as far as I can tell, but could use more tests. I
would like to finish the core functionality before 1.4.0 and will try
to do that, but there is still quite a bit of work to be done.
If it is not finished, then we can keep the code there, and just
document what works and what remains to be completed.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion