1.19 release

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

1.19 release

Charles R Harris
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

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: 1.19 release

ralfgommers


On Sat, Oct 12, 2019 at 3:21 AM Charles R Harris <[hidden email]> 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


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: 1.19 release

Charles R Harris


On Sat, Oct 12, 2019 at 9:58 AM Ralf Gommers <[hidden email]> wrote:


On Sat, Oct 12, 2019 at 3:21 AM Charles R Harris <[hidden email]> 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 

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: 1.19 release

ralfgommers


On Sat, Oct 12, 2019 at 7:14 PM Charles R Harris <[hidden email]> wrote:


On Sat, Oct 12, 2019 at 9:58 AM Ralf Gommers <[hidden email]> wrote:


On Sat, Oct 12, 2019 at 3:21 AM Charles R Harris <[hidden email]> 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


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: 1.19 release

Sebastian Berg
In reply to this post by Charles R Harris
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
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment