Proposed change in construction of structured dtypes with a shape-(1, ) field

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

Proposed change in construction of structured dtypes with a shape-(1, ) field

Antony Lee
In #13112/#13326, I proposed to change the semantics of constructing structured dtypes with a shape-(1,) field (with a deprecation period).  Currently, a construct like `np.empty(1, ("a", int, 1))` is treated as a shape-() field, i.e. the same as `np.empty(1, ("a", int))`; the PR proposes to (ultimately) change it to mean using a shape-(1,) field, i.e. `np.empty(1, ("a", int, 1))`.  This is consistent e.g. with `np.empty(1, ("a", int, 2))` being equivalent to `np.empty(1, ("a", int, (2,)))` and more generally with numpy accepting a scalar integer n to mean shape-(n,) in many places (e.g. `np.zeros(3)` and `np.zeros((3,))`).

Thoughts?

Antony

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

Re: Proposed change in construction of structured dtypes with a shape-(1, ) field

Stefan van der Walt
Hi Anthony,

On Mon, 20 May 2019 16:51:54 +0200, Antony Lee wrote:

> In #13112/#13326, I proposed to change the semantics of constructing
> structured dtypes with a shape-(1,) field (with a deprecation period).
> Currently, a construct like `np.empty(1, ("a", int, 1))` is treated as a
> shape-() field, i.e. the same as `np.empty(1, ("a", int))`; the PR proposes
> to (ultimately) change it to mean using a shape-(1,) field, i.e.
> `np.empty(1, ("a", int, 1))`.  This is consistent e.g. with `np.empty(1,
> ("a", int, 2))` being equivalent to `np.empty(1, ("a", int, (2,)))` and
> more generally with numpy accepting a scalar integer n to mean shape-(n,)
> in many places (e.g. `np.zeros(3)` and `np.zeros((3,))`).
>
> Thoughts?

Your change doesn't seem to complicate the function, and improves
consistency.  So, +1.

I also think this falls into the bin of "corner cases with marginal gain
that we shouldn't spend developer/review time on", but since you already
have the review completed, that point is moot.

Best regards,
Stéfan
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion