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)
Today both of the python.org mailing lists I'm subscribed to (numpy and
scipy-dev) got the same kind of link shortener spam. I assume all the
mailing lists started getting these, and that these won't go away for a
Is there any way to prevent these, short of moderating emails from new list
members? Assuming the engine even supports that. There aren't many emails,
especially from new members, and I can't think of other ways that ensure no
false positives in filtering.
Since maintainer time is precious, I can volunteer to moderate such emails
Our bi-weekly triage-focused NumPy development meeting is Wednesday,
September 8th at 9 am Pacific Time (16:00 UTC).
Everyone is invited to join in and edit the work-in-progress meeting
topics and notes:
I encourage everyone to notify us of issues or PRs that you feel should
be prioritized, discussed, or reviewed.
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?
Melissa brought up that we should reschedule the bi-weekly community
meeting to the same time slot at the triage meeting:
Wednesdays 16:00 UTC (9 am Pacific time) 
This will simplify attending for those in Europe and allow a more
reasonable time including for India.
As of now, all regular attendees are happy with this move. But the
original idea was that we could also alternate between two times, the
current time is e.g. impossible to make from east Asia.
Please let me/us know if you prefer a different schedule now (or
later!). The idea is that these meetings are accessible to anyone
Without any comments, I will announce and change the calendar starting
with next weeks meeting.
 I have to see whether we will stick with UTC or do any daylight
The np.choose function raises a ValueError if called with more than 31
This PR adds an alternate implementation np.extended_choose (which uses the
base implementation) that supports any number of choices.
FYI, I needed this functionality for a mouse embryo microscopy tool I'm
I'm attempting to contribute it because I thought it might be generally
All comments, complaints, or suggestions or code reviews appreciated.
thanks! -- Aaron Watters
I just installed NumPy using pip and Python 3.9.7 on CentOS 7.9.
Installation went fine, but when I ran
>>> import numpy
I got a traceback, and this summary.
=========================== short test summary info ============================
ERROR - ModuleNotFoundError: No module named 'hypothesis'
!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
It seems that both hypothesis and pytest are needed to run numpy.test().
We like to be able to run all the tests even after a pip install, and
being able to run some of the tests from pip-installed numpy is useful
May I suggest you add those two packages as dependencies for NumPy at
PyPi? Neither are particularly large, both are generally useful, and
I think the potential utility for those who would ike to check on
their own system for anomalies outweighs the minimal impact on the
majority of users who would not use it but would also probably not
notice their presence.
If adding them as dependencies seems to heavy weight, or is otherwised
deemed undesirable, perhaps just a note in the Project Description at
https://pypi.org/project/numpy/ to say that, if you want to run tests,
those two packages will be needed?
Thanks, -- bennet