Hi All, Thought I'd raise the option of trying to put together an NEP for the 1.18 release like Python does PEPs. If that is considered too procedural for releases that come out every six months or so, are there any suggestions for an alternative? About 1.19 itself, I expect to fork 1.18.x in the middle of next month aiming at a release in late December. The main task I currently see for 1.19 is to remove the shims for Python 2.7 and 3.5, there are already a couple of delayed PRs along that line. If there are other things that folks think should be on the todo list, suggestions are welcome. Chuck
On Sat, Oct 12, 2019 at 3:21 AM Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
Thought I'd raise the option of trying to put together an NEP for the 1.18 release like Python does PEPs. If that is considered too procedural for releases that come out every six months or so, are there any suggestions for an alternative?
The Python one only contains a release schedule, and gets updated later with a small subset of the release notes: https://www.python.org/dev/peps/pep-0494/. I guess its main audience is packagers and companies needing to plan ahead supporting a new Python version. What would you like to put in such a NEP?
About 1.19 itself, I expect to fork 1.18.x in the middle of next month aiming at a release in late December. The main task I currently see for 1.19 is to remove the shims for Python 2.7 and 3.5, there are already a couple of delayed PRs along that line. If there are other things that folks think should be on the todo list, suggestions are welcome.
For 1.18 I think the main things are further changes to numpy.random and the dispatch system. For 1.19 not sure, that still feels far away. Cheers, Ralf
On Sat, Oct 12, 2019 at 9:58 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Oct 12, 2019 at 3:21 AM Charles R Harris < charlesr.harris@gmail.com> wrote:
Hi All,
Thought I'd raise the option of trying to put together an NEP for the 1.18 release like Python does PEPs. If that is considered too procedural for releases that come out every six months or so, are there any suggestions for an alternative?
The Python one only contains a release schedule, and gets updated later with a small subset of the release notes: https://www.python.org/dev/peps/pep-0494/. I guess its main audience is packagers and companies needing to plan ahead supporting a new Python version.
What would you like to put in such a NEP?
About 1.19 itself, I expect to fork 1.18.x in the middle of next month aiming at a release in late December. The main task I currently see for 1.19 is to remove the shims for Python 2.7 and 3.5, there are already a couple of delayed PRs along that line. If there are other things that folks think should be on the todo list, suggestions are welcome.
For 1.18 I think the main things are further changes to numpy.random and the dispatch system. For 1.19 not sure, that still feels far away.
Agree about numpy.random. What changes are you looking for in the dispatch system? Chuck
On Sat, Oct 12, 2019 at 7:14 PM Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sat, Oct 12, 2019 at 9:58 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Oct 12, 2019 at 3:21 AM Charles R Harris < charlesr.harris@gmail.com> wrote:
Hi All,
Thought I'd raise the option of trying to put together an NEP for the 1.18 release like Python does PEPs. If that is considered too procedural for releases that come out every six months or so, are there any suggestions for an alternative?
The Python one only contains a release schedule, and gets updated later with a small subset of the release notes: https://www.python.org/dev/peps/pep-0494/. I guess its main audience is packagers and companies needing to plan ahead supporting a new Python version.
What would you like to put in such a NEP?
About 1.19 itself, I expect to fork 1.18.x in the middle of next month aiming at a release in late December. The main task I currently see for 1.19 is to remove the shims for Python 2.7 and 3.5, there are already a couple of delayed PRs along that line. If there are other things that folks think should be on the todo list, suggestions are welcome.
For 1.18 I think the main things are further changes to numpy.random and the dispatch system. For 1.19 not sure, that still feels far away.
Agree about numpy.random. What changes are you looking for in the dispatch system?
Plugging some of the gaps, like the array creation and asarray stuff at a minimum, since those are the most painful missing capabilities. Peter Entschev has given us some of the clearest use cases. There's still quite a bit of work to do and decisions to make. If it doesn't materialize in time then so be it, but it's a good goal for the next release. Cheers, Ralf
On Fri, 2019-10-11 at 19:20 -0600, Charles R Harris wrote:
Hi All,
Thought I'd raise the option of trying to put together an NEP for the 1.18 release like Python does PEPs. If that is considered too procedural for releases that come out every six months or so, are there any suggestions for an alternative?
About 1.19 itself, I expect to fork 1.18.x in the middle of next month aiming at a release in late December. The main task I currently see for 1.19 is to remove the shims for Python 2.7 and 3.5, there are already a couple of delayed PRs along that line. If there are other things that folks think should be on the todo list, suggestions are welcome.
I am thinking whether there may be some more deprecations to put on the list. These are mostly only mildly annoying, so it is also not a high priority. The first thing is the CHAR dtype, which seems already deprecated on the C-Side, but `np.dtype("c")` still works [0]. It is not a big hassle, but it seems like an oversight that it is not deprecated? The other thing I would like to bring up is deprecating the `PyArray_GetArrayParamsFromObject` function: 1. I have difficulty seeing anyone using it, it has some strange behaviour: the dtype it returns (if you pass in one) depends on whether or not the output is a numpy-scalar. I think everyone would simply use `PyArray_FromAny`, since they probably want an array in either case. 2. It is not really useful currently for flexible dtypes at all, since you need AdaptFlexibleDType in that case, and that is not exposed. 3. We need to replace array coercion, keeping this interface around means compatibility guarantees. I currently reproduce it faithfully, but if we disable the function, it means we can delete all the code and also not worry about adding tests to ensure compatibility indefinitely. However, we have no replacement except conversion to array. Experience tells us that every dark corner is used by someone, but maybe we can risk breaking that (hopefully) one person? Looking through the C-API some more, we could also consider deprecating and removing (in the sense of always error return) these: * PyArray_ObjectType * PyArray_ArrayType * PyArray_ScalarKind which have been superseded since NumPy 1.6. `PyArray_MinScalarType` we probably should keep around, although we need a replacement. Which should just be a replacement for `PyArray_GetArrayParamsFromObject` [1]. I have to look at the scalar API, but there may be some candidates there as well. Best, Sebastian [0] The only thing it seems to do is change how strings are parsed in `np.asarray` calls. Otherwise it is pretty much equivalent to "S1", but who knows maybe people use it... [1] I personally would like us to stop doing value based casting for typed 0-D arrays and scalars. So at that point a "minimal scalar" dtype only makes sense for python types. I feel if you know that you want to downcast, you can use "same_kind" casting.
Chuck _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
participants (3)
-
Charles R Harris -
Ralf Gommers -
Sebastian Berg