The following proposal was originally issue #16722 on GitHub but at
the request of Matti Picus I am moving the discussion to this list.
"NumPy is the fundamental package needed for scientific computing with Python."
I am asking the NumPy project to leverage its position as a core
dependency among statistical, numerical, and ML projects, in the
pursuit of climate justice. It is easy to identify open-source
software used by the oil and gas industry which relies on NumPy 
 , and it is highly likely that NumPy is used in closed-source and
in-house software at oil and gas extraction companies such as Aramco,
ExxonMobil, BP, Shell, and others. I believe it is possible to use
software licensing to discourage the use of NumPy and dependent
packages by companies such as these, and that doing so would frustrate
the ability of these companies to identify and extract new oil and gas
I propose NumPy's current BSD 3-Clause license be extended to include
the following conditions, in line with the Climate Strike License 
* The Software may not be used in applications and services that
are used for or
aid in the exploration, extraction, refinement, processing, or
of fossil fuels.
* The Software may not be used by companies that rely on fossil
as their primary means of revenue. This includes but is not
limited to the
companies listed at https://climatestrike.software/blocklist
I accept that there are issues around adopting such a proposal, including that:
addition of such clauses violates the Open Source Initiative's
canonical Open Source Definition, which explicitly excludes licenses
that limit re-use "in a specific field of endeavor", and therefore if
these clauses were adopted NumPy would no longer "be open-source" by
there may be collateral damage among the wider user base and project
sponsorship, due to the vague nature of the first clause, and this may
affect the longevity of the project and its standing within the
Python, numerical, statistical, and ML communities.
My intention with the opening of this issue is to promote constructive
discussion of the use of software licensing -- and other measures --
for working towards climate justice -- and other forms of justice --
in the context of NumPy and other popular open-source libraries. Some
people will say that NumPy is "just a tool" and that it sits
independent of how it is used, but due to its utility and its
influence as a major open-source library, I think it is essential that
we consider the position of the Climate Strike License authors, that
"as tech workers, we should take responsibility in how our software is
Many thanks to all of the contributors who have put so much time and
energy into NumPy. ✨ ❤️ 😃
Yes, it’s a survey. But it’s very important.
Having limited human and financial resources is a common challenge for open
source projects. NumPy is not an exception. Please join this structured
dialogue with the NumPy leadership team to better guide and prioritize
decision-making about the development of NumPy as software and a community.
What started as a humble project by a dedicated core of user-developers has
since transformed into a foundational component of the widely-adopted
scientific Python ecosystem used by millions worldwide. To engage
non-English speaking stakeholders, the inaugural NumPy community survey is
offered in 7 additional languages: Bangla, Hindi, Japanese, Mandarin,
Portuguese, Russian, and Spanish.
The survey will take about 15 minutes of your time and close on July
here <https://umdsurvey.umd.edu/jfe/form/SV_8bJrXjbhXf7saAl> to get started.
NumPy Survey Team
As a follow up to gh-15981 <https://github.com/numpy/numpy/issues/15981>, I
would like to propose a change to bring complex dtype(s) comparison
operators and related functions, in line with respective cpython
The current state of complex dtype comparisons/ordering as summarised in
the issue is as follows:
# In python
>> cnum = 1 + 2j
>> cnum_two = 1 + 3j
# Doing a comparision yields
>> cnum > cnum_two
TypeError: '>' not supported between instances of 'complex' and 'complex'
# Doing the same in Numpy scalar comparision
>> np.array(cnum) > np.array(cnum_two)
*NOTE*: only >, <, >= , <= do not work on complex numbers in python ,
equality (==) does work
similarly sorting uses comparison operators behind to sort complex values.
Again this behavior diverges from the default python behavior.
# In native python
>> clist = [cnum, cnum_2]
>> sorted(clist, key=lambda c: (c.real, c.imag))
# In numpy
>> np.sort(clist) #Uses the default comparision order
# Yields same result
# To get a cpython like sorting call we can do the following in numpy
np.take_along_axis(clist, np.lexsort((clist.real, clist.imag), 0), 0)
This proposal aims to bring parity between default python handling of
complex numbers and handling complex types in numpy
This is a two-step process
1. Sort complex numbers in a pythonic way , accepting key arguments, and
deprecate usage of sort() on complex numbers without key argument
1. Possibly extend this to max(), min(), if it makes sense to do so.
2. Since sort() is being updated for complex numbers, searchsorted()
is also a good candidate for implementing this change.
2. Once this is done, we can deprecate the usage of comparison operators
(>, <, >= , <=) on complex dtypes
*Handling sort() for complex numbers*
There are two approaches we can take for this
1. update sort() method, to have a ‘key’ kwarg. When key value is
passed, use lexsort to get indices and continue sorting of it. We could
support lambda function keys like python, but that is likely to be very
2. Create a new wrapper function sort_by() (placeholder name, Requesting
name suggestions/feedback)That essentially acts like a syntactic sugar for
1. np.take_along_axis(clist, np.lexsort((clist.real, clist.imag), 0),
1. Improve the existing sort_complex() method with the new key search
functionality (Though the change will only reflect for complex dtypes).
We could choose either method, both have pros and cons , approach 1 makes
the sort function signature, closer to its python counterpart, while using
approach 2 provides a better distinction between the two approaches for
sorting. The performance on approach 1 function would vary, due to the key
being an optional argument. Would love the community’s thoughts on this.
*Handling min() and max() for complex numbers*
Since min and max are essentially a set of comparisons, in python they are
not allowed on complex numbers
>> clist = [cnum, cnum_2]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: '<' not supported between instances of 'complex' and 'complex'
# But using keys argument again works
min(clist, key=lambda c: (c.real, c.imag))
We could use a similar key kwarg for min() and max() in python, but
question remains how we handle the keys, in this use case , naive way would
be to sort() on keys and take last or first element, which is likely going
to be slow. Requesting suggestions on approaching this.
*Comments on isclose()*
Both python and numpy use the absolute value/magnitude for comparing if two
values are close enough. Hence I do not see this change affecting this
Requesting feedback and suggestions on the above.
I’m still in the process of scheduling live networking sessions at SciPy’20
and would be happy to set up one on the topic of Python for Climate Action.
We could host it on July 8th or 10th at 5 - 6 p.m. CDT. Would you be
available to moderate it?
> ---------- Forwarded message ----------
> From: Juan Nunez-Iglesias <jni(a)fastmail.com>
> To: Discussion of Numerical Python <numpy-discussion(a)python.org>
> Date: Thu, 2 Jul 2020 18:58:11 +1000
> Subject: Re: [Numpy-discussion] Proposal to add clause to license
> prohibiting use by oil and gas extraction companies
> Hi everyone,
> If you live in Australia, this has been a rough year to think about
> climate change. After the hottest and driest year on record, over 20% of
> the forest surface area of the south east was burned in the bushfires.
> Although I was hundreds of kilometres from the nearest fire, the air
> quality was rated as hazardous for several days in my city. This brought
> home for me two points.
> One, that "4ºC" is not about taking off a jumper and going to the beach
> more often, but actually represents a complete transformation of our
> planet. 4ºC is what separates us from the last ice age, so we can expect
> our planet in 80 years to be as unrecognisable from today as today is from
> the ice age.
> Two, that climate change is already with us, and we can't just continue to
> ignore the problem and enjoy whatever years of climate peace we thought we
> had left. Greta has it right, we are running out of time and absolutely
> drastic action is needed.
> All this is a prelude to add my voice to everyone who has already said
> that *messing with the NumPy license is absolutely *not* the drastic
> action needed*, and will be counter-productive, as many have noted.
> Having said this, I'm happy that the community is getting involved and
> getting active and coming up with creative ideas to do their part. If
> someone wants to start a "Pythonistas for Climate Action" user group, I'll
> be the first to join. I had planned to give a lightning talk in the vein of
> the above at SciPy, which, and believe me that I hate to hate on my
> favourite conference, recently loudly thanked Shell  for being a
> platinum sponsor. (Not to mention that Enthought derives about a third of
> its income from fossil fuel companies.) Unfortunately and for obvious
> reasons I won't make it to SciPy after all, but again, I'm happy to see the
> community rising.
> Perhaps this is derailing the discussion, but, anyone up for a "Python for
> Climate Action" BoF at the conference? I can probably make the
> late-afternoon BoFs given the time difference.
> : https://twitter.com/SciPyConf/status/1276898138977193984
Every good wish,