(sorry for the length, details/discussion below)
On the triage call, there seemed a preference to just try to skip the
deprecation and introduce `copy="never"`, `copy="if_needed"`, and
`copy="always"` (i.e. string options for the `copy` keyword argument).
Strictly speaking, this is against the typical policy (one year of
warning/errors). But nobody could think of a reasonable chance that
anyone actually uses it. (For me just "policy" will be enough of an
argument to just take it slow.)
BUT: If nobody has *any* concerns at all, I think we may just end up
introducing the change right away.
The PR is: https://github.com/numpy/numpy/pull/19173
## The Feature
There is the idea to add `copy=never` (or similar). This would modify
the existing `copy` argument to make it a 3-way decision:
* `copy=always` or `copy=True` to force a copy
* `copy=if_needed` or `copy=False` to prefer no-copy behavior
* `copy=never` to error when no-copy behavior is not possible
(this ensures that a view is returned)
this would affect the functions:
* np.array(object, copy=...)
* arr.astype(new_dtype, copy=...)
* np.reshape(arr, new_shape, copy=...), and the method arr.reshape()
* np.meshgrid and possibly
Where `reshape` currently does not have the option and would benefit by
allowing for `arr.reshape(-1, copy=never)`, which would guarantee a
## The Options
We have three options that are currently being discussed:
1. We introduce a new `np.CopyMode` or `np.<something>.Copy` Enum
with values `np.CopyMode.NEVER`, `np.CopyMode.IF_NEEDED`, and
* Plus: No compatibility concerns
* Downside(?): This would be a first in NumPy, and is untypical
API due to that.
2. We introduce `copy="never"`, `copy="if_needed"` and `copy="always"`
as strings (all other strings will be a `TypeError`):
* Problem: `copy="never"` currently means `copy=True` (the opposite)
Which means new code has to take care when it may run on
older NumPy versions. And in theory could make old code
return the wrong thing.
* Plus: Strings are the typical for options in NumPy currently.
3. Same as 2. But we take it very slow: Make strings an error right now
and only introduce the new options after two releases as per typical
We discussed it briefly today in the triage call and we were leaning
I was honestly expecting to converge to option 3 to avoid compatibility
issues (mainly surprises with `copy="never"` on older versions).
But considering how weird it is to currently pass `copy="never"`, the
question was whether we should not change it with a release note.
The probability of someone currently passing exactly one of those three
(and no other) strings seems exceedingly small.
Personally, I don't have a much of an opinion. But if *nobody* voices
any concern about just changing the meaning of the string inputs, I
think the current default may be to just do it.
In regard to Feature Request: https://github.com/numpy/numpy/issues/16469
It was suggested to sent to the mailing list. I think I can make a strong
point as to why the support for this naming convention would make sense.
Such as it would follow other frameworks that often work alongside numpy
such as tensorflow. For backward compatibility, it can simply be an alias
I often convert portions of code from tf to np, it is as simple as changing
the base module from tf to np. e.g. np.expand_dims -> tf.expand_dims. This
is done either in debugging (e.g. converting tf to np without eager
execution to debug portion of the code), or during prototyping, e.g.
develop in numpy and convert in tf.
I find myself more than at one occasion to getting syntax errors because of
this particular function np.concatenate. It is unnecessarily long. I
imagine there are more people that also run into the same problems. Pandas
uses concat (torch on the other extreme uses simply cat, which I don't
think is as descriptive).
FYI, I noticed this package that claimed to be maintained by us:
https://pypi.org/project/numpy-aarch64/. That's not ours, so I tried to
contact the author (no email provided, but guessed the same username on
GitHub) and asked to remove it:
There are a very large number of packages with "numpy" in the name on PyPI,
and there's no way we can audit/police that effectively, but if it's a
rebuild that pretends like it's official then I think it's worth doing
something about. It could contain malicious code for all we know.
It would be nice to be able to use the Python syntax we already use to
format the precision of floating numbers in numpy:
>>> a = np.array([-np.pi, np.pi])
This is particularly useful when you have large arrangements. The problem
is that if you want to do it today, it is not implemented:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported format string passed to numpy.ndarray.__format__
In this PR (https://github.com/numpy/numpy/pull/19550) I propose a very
basic formatting implementation for numeric numbers that uses
`array2string` just like it currently does `str`
At first, since we are only considering formatting the numeric type,
floating numbers specifically, we are only interested in being able to
change the precision, the sign, and possibly the rounding or truncation.
Since the `array2string` function already does everything we need, we only
need to implement the` __format__` function of the `ndarray` class which
parses a predefined format (similar to the one already used by Python for
built-in data types) to indicate the parameters before said.
I propose a mini format specification inspired in the [Format Specification
format_spec ::= [sign][.precision][type]
sign ::= "+" | "-" | " "
precision ::= [0-9]+
type ::= "f" | "e"
We are going to consider only 3 arguments of the `array2string` function:`
precision`, `suppress_small`,` sign`. In particular, the `type` token sets
the` suppress_small` argument to True when the type is `f` and False when
it is `e`. This is in order to mimic Python's behavior in truncating
decimals when using the fixed-point notation.
As @brandon-rhodes said in gh-5543, the behavior when you try to format an
array containing Python objects, the behavior should be the same as Python
has implemented by default in the `object` class: ` format (a, "") ` should
be equivalent to `str (a)` and `format(a, "not empty")` should raise an
What remains to be defined is the behavior when trying to format an array
with a non-numeric data type (`np.numeric`) other than `np.object_`. Should
we raise an exception? In my opinion yes, since in the future formatting is
extended -- for example, for dates -- people are aware that before that was
I'm open to suggestions.
In NumPy 1.21, the output of `np.unique` changed in the presence of
multiple NaNs. Previously, all NaNs were returned when we now only
return one (all NaNs were considered unique):
a = np.array([1, 1, np.nan, np.nan, np.nan])
array([ 1., nan, nan, nan])
array([ 1., nan])
This change was requested in an old issue:
And happened here:
While, it has a release note. I am not sure the change got the
attention it deserved. This would be especially worrying if it is a
regression for anyone?
PS: One additional note, is that this does not work for object arrays
(it cannot reasonable):
array([1.0, nan, nan, nan], dtype=object)
https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step
toward getting rid of generated C code within numpy, in favor of some C++ code,
coupled with a single macro trick.
Basically, templated code is an easy and robust way to replace generated code
(the C++ compiler becomes the code generator when instantiating code), and a
single X-macro takes care of the glue with the C world.
Some changes in distutils were needed to cope with C++-specific flags, and
extensions that consist in mixed C and C++ code.
I've kept the change as minimal as possible to ease the (potential) transition
and keep the C++ code close to the C code. This led to less idiomatic C++ code,
but I value a "correct first" approach. There's an on-going effort by seiko2plus
to remove that C layer, I acknowledge this would bring even more C++ code, but
that looks orthogonal to me (and a very good second step!)
All lights are green for the PR, let's assume it's a solid ground for discussion :-)
So, well, what do you think? Should we go forward?
Potential follow-ups :
- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep?
- what about -fno-exception, -fno-rtti?
- coding style?
We are happy to announce the Chan Zuckerberg Initiative has awarded a grant
to support the onboarding, inclusion, and retention of people from
historically marginalized groups on scientific Python projects, and to
structurally improve the community dynamics for NumPy, SciPy, Matplotlib,
As a part of CZI’s Essential Open Source Software for Science program ,
this Diversity & Inclusion supplemental grant  will support the creation
of dedicated Contributor Experience Lead positions to identify, document,
and implement practices to foster inclusive open-source communities. This
project will be led by Melissa Mendonça (NumPy), with additional mentorship
and guidance provided by Ralf Gommers (NumPy, SciPy), Hannah Aizenman and
Thomas Caswell (Matplotlib), Matt Haberland (SciPy), and Joris Van den
This is an ambitious project aiming to discover and implement activities
that should structurally improve the community dynamics of our projects. By
establishing these new cross-project roles, we hope to introduce a new
collaboration model to the Scientific Python communities, allowing
community-building work within the ecosystem to be done more efficiently
and with greater outcomes. We also expect to develop a clearer picture of
what works and what doesn’t in our projects to engage and retain new
contributors, especially from historically underrepresented groups.
Finally, we plan on producing detailed reports on the actions executed,
explaining how they have impacted our projects in terms of representation
and interaction with our communities.
The two-year project is expected to start by November 2021, and we are
excited to see the results from this work! You can read the full proposal
in figshare  and see this announcement at the NumPy site .
Hi, it is my first contribution to the open-source community, I have tried
to fix issue #19315, which is to add a new feature of rotating mesh grid in
NumPy. It would be great if I get improvements and suggestions for it.
Added functionality of rotating mesh grid which fixes #19315 issue, adds a
feature which works as follows
xspan : Input_array
range of values of x in the unrotated matrix.
yspan : Input_array
range of values of y in the unrotated matrix.
angle : float or int
Angle of rotation, positive for clockwise rotation, negative for
boolRad : bool
True if the given angle is in Radians, False if given angle is
out : ndarray
A new nested array is generated by Einstein Summation after
rotation is applied.
>>> xspan = np.linspace(-2*np.pi, 2*np.pi, 3)
>>> yspan = np.linspace(-2*np.pi, 2*np.pi, 3)
>>> arr = np.rotateMeshgrid(xspan,yspan,0.4)
array([[[-6.32689674, -0.04386455, 6.23916764],
[-6.28303219, 0. , 6.28303219],
[-6.23916764, 0.04386455, 6.32689674]],
[[-6.23916764, -6.28303219, -6.32689674],
[ 0.04386455, 0. , -0.04386455],
[ 6.32689674, 6.28303219, 6.23916764]]])
>>> arr = np.rotateMeshgrid(xspan,yspan,80,False)
array([[[ 6.9383701 , 6.24478659, 5.55120308],
[ 0.69358351, 0. , -0.69358351],
[-5.55120308, -6.24478659, -6.9383701 ]],
[[-5.55120308, 0.69358351, 6.9383701 ],
[-6.24478659, 0. , 6.24478659],
[-6.9383701 , -0.69358351, 5.55120308]]])