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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
