label NA and datetime as experimental
Hi, We decided to label both NA and datetime APIs as experimental for the 1.7.0 release. I made a PR that does this, please review: https://github.com/numpy/numpy/pull/240 Ralf
Hi, My team are currently experimenting with extending datetime to allow alternative, non-physical calendars (e.g. 360-day used by climate modellers). Once we've got a handle on the options we'd like to propose the extensions/changes back to NumPy. Obviously we'd like to avoid wasted effort, so are there some aspects of datetime64 which are more experimental than others? Is there a summary of unresolved issues and/or plans for change? Thanks, Richard Hattersley On 25 March 2012 13:57, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Hi,
We decided to label both NA and datetime APIs as experimental for the 1.7.0 release. I made a PR that does this, please review: https://github.com/numpy/numpy/pull/240
Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Mar 26, 2012 at 2:29 AM, Richard Hattersley <rhattersley@gmail.com>wrote:
Hi,
My team are currently experimenting with extending datetime to allow alternative, non-physical calendars (e.g. 360-day used by climate modellers). Once we've got a handle on the options we'd like to propose the extensions/changes back to NumPy. Obviously we'd like to avoid wasted effort, so are there some aspects of datetime64 which are more experimental than others? Is there a summary of unresolved issues and/or plans for change?
I believe datetime is already used by Pandas, so I don't think there will be major changes there. I'm not aware of open issues, but I could be wrong. The calenders are a bit independent, so I think the best procedure is to go ahead with your work. We want to leave some wiggle room since new features often need a little time to mature. That's how it looks to me anyway. Chuck
On Mon, Mar 26, 2012 at 5:42 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Mon, Mar 26, 2012 at 2:29 AM, Richard Hattersley <rhattersley@gmail.com
wrote:
Hi,
My team are currently experimenting with extending datetime to allow alternative, non-physical calendars (e.g. 360-day used by climate modellers). Once we've got a handle on the options we'd like to propose the extensions/changes back to NumPy. Obviously we'd like to avoid wasted effort, so are there some aspects of datetime64 which are more experimental than others? Is there a summary of unresolved issues and/or plans for change?
I believe datetime is already used by Pandas, so I don't think there will be major changes there. I'm not aware of open issues, but I could be wrong. The calenders are a bit independent, so I think the best procedure is to go ahead with your work. We want to leave some wiggle room since new features often need a little time to mature. That's how it looks to me anyway.
That's my understanding too. Perhaps Mark can comment on the current status. That status and changes need to still be described in the release notes by the way. The experimental tag is mostly due to the datetime history: it was introduced in 1.4.0, removed again in 1.4.1, reintroduced in 1.6.0, the API then labeled not useful ( http://thread.gmane.org/gmane.comp.python.numeric.general/44162/focus=44385), then more changes for this release. I hope it's stable now, but seeing what came before and that it still doesn't work with MinGW it's hard to be sure. Ralf
OK - that's useful feedback. Thanks! On 26 March 2012 21:03, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Mon, Mar 26, 2012 at 5:42 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Mon, Mar 26, 2012 at 2:29 AM, Richard Hattersley <rhattersley@gmail.com> wrote:
Hi,
My team are currently experimenting with extending datetime to allow alternative, non-physical calendars (e.g. 360-day used by climate modellers). Once we've got a handle on the options we'd like to propose the extensions/changes back to NumPy. Obviously we'd like to avoid wasted effort, so are there some aspects of datetime64 which are more experimental than others? Is there a summary of unresolved issues and/or plans for change?
I believe datetime is already used by Pandas, so I don't think there will be major changes there. I'm not aware of open issues, but I could be wrong. The calenders are a bit independent, so I think the best procedure is to go ahead with your work. We want to leave some wiggle room since new features often need a little time to mature. That's how it looks to me anyway.
That's my understanding too. Perhaps Mark can comment on the current status. That status and changes need to still be described in the release notes by the way.
The experimental tag is mostly due to the datetime history: it was introduced in 1.4.0, removed again in 1.4.1, reintroduced in 1.6.0, the API then labeled not useful (http://thread.gmane.org/gmane.comp.python.numeric.general/44162/focus=44385), then more changes for this release. I hope it's stable now, but seeing what came before and that it still doesn't work with MinGW it's hard to be sure.
Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
participants (3)
-
Charles R Harris -
Ralf Gommers -
Richard Hattersley