Proposed change in construction of structured dtypes with a shape-(1, ) field
![](https://secure.gravatar.com/avatar/d4749d18577f8642b90f271b6aefe9fe.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/d9ac9213ada4a807322f99081296784b.jpg?s=120&d=mm&r=g)
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
participants (2)
-
Antony Lee
-
Stefan van der Walt