Mailman 3 July 2020 - NumPy-Discussion

mixed mode arithmetic
by Neal Becker July 11, 2023

July 11, 2023

I've been browsing the numpy source. I'm wondering about mixed-mode arithmetic on arrays. I believe the way numpy handles this is that it never does mixed arithmetic, but instead converts arrays to a common type. Arguably, that might be efficient for a mix of say, double and float. Maybe not. But for a mix of complex and a scalar type (say, CDouble * Double), it's clearly suboptimal in efficiency. So, do I understand this correctly? If so, is that something we should improve?

4 6

Invalid value encoutered : how to prevent numpy.where to do this?
by Eric Emsellem Feb. 18, 2023

Feb. 18, 2023

Dear all, I have a code using lots of "numpy.where" to make some constrained calculations as in: data = arange(10) result = np.where(data == 0, 0., 1./data) # or data1 = arange(10) data2 = arange(10)+1.0 result = np.where(data1 > data2, np.sqrt(data1-data2), np.sqrt(data2-data2)) which then produces warnings like: /usr/bin/ipython:1: RuntimeWarning: invalid value encountered in sqrt or for the first example: /usr/bin/ipython:1: RuntimeWarning: divide by zero encountered in divide How … [View More]

5 4

Documentation Team meeting - Monday June 8th
by Melissa Mendonça Dec. 3, 2022

Dec. 3, 2022

Hi all! A reminder that on Monday, June 8, we have another documentation team meeting at 3PM UTC**. If you wish to join on Zoom, you need to use this link https://zoom.us/j/420005230 Here's the permanent hackmd document with the meeting notes: https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg <https://www.google.com/url?q=https%3A%2F%2Fhackmd.io%2FoB_boakvRqKR-_2jRV-Q…> Hope to see you around (especially if you want to introduce yourself or discuss ideas for Google Season of Docs). ** You … [View More]

6 74

[Feature Request] Add alias of np.concatenate as np.concat
by Iordanis Fostiropoulos May 10, 2022

May 10, 2022

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 to np.concatenate 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. … [View More]

7 6

Re: [Numpy-discussion] example reading binary Fortran file
by Neil Martinsen-Burrell July 22, 2021

July 22, 2021

David Froger <david.froger.info <at> gmail.com> writes: > Hy,My question is about reading Fortran binary file (oh no this question > again...) I've posted this before, but I finally got it cleaned up for the Cookbook. For this purpose I use a subclass of file that has methods for reading unformatted Fortran data. See http://www.scipy.org/Cookbook/FortranIO/FortranFile. I'd gladly see this in numpy or scipy somewhere, but I'm not sure where it belongs. > program … [View More]makeArray > implicit none > integer,parameter:: nx=10,ny=20 > real(4),dimension(nx,ny):: ux,uy,p > integer :: i,j > open(11,file='uxuyp.bin',form='unformatted') > do i = 1,nx > do j = 1,ny > ux(i,j) = real(i*j) > uy(i,j) = real(i)/real(j) > p (i,j) = real(i) + real(j) > enddo > enddo > write(11) ux,uy > write(11) p > close(11) > end program makeArray When I run the above program compiled with gfortran on my Intel Mac, I can read it back with:: >>> import numpy as np >>> from fortranfile import FortranFile >>> f=FortranFile('uxuyp.bin', endian='<') >>> uxuy = f.readReals(prec='f') # 'f' for default reals >>> len(uxuy) 400 >>> ux = np.array(uxuy[:200]).reshape((20,10)).T >>> uy = np.array(uxuy[200:]).reshape((20,10)).T >>> p = f.readReals('f').reshape((20,10)).T >>> ux array([[ 1., 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20.], [ 2., 4., 6., 8., 10., 12., 14., 16., 18., 20., 22., 24., 26., 28., 30., 32., 34., 36., 38., 40.], [ 3., 6., 9., 12., 15., 18., 21., 24., 27., 30., 33., 36., 39., 42., 45., 48., 51., 54., 57., 60.], [ 4., 8., 12., 16., 20., 24., 28., 32., 36., 40., 44., 48., 52., 56., 60., 64., 68., 72., 76., 80.], [ 5., 10., 15., 20., 25., 30., 35., 40., 45., 50., 55., 60., 65., 70., 75., 80., 85., 90., 95., 100.], [ 6., 12., 18., 24., 30., 36., 42., 48., 54., 60., 66., 72., 78., 84., 90., 96., 102., 108., 114., 120.], [ 7.,Proxy-Connection: keep-alive Cache-Control: max-age=0 14., 21., 28., 35., 42., 49., 56., 63., 70., 77., 84., 91., 98., 105., 112., 119., 126., 133., 140.], [ 8., 16., 24., 32., 40., 48., 56., 64., 72., 80., 88., 96., 104., 112., 120., 128., 136., 144., 152., 160.], [ 9., 18., 27., 36., 45., 54., 63., 72., 81., 90., 99., 108., 117., 126., 135., 144., 153., 162., 171., 180.], [ 10., 20., 30., 40., 50., 60., 70., 80., 90., 100., 110., 120., 130., 140., 150., 160., 170., 180., 190., 200.]]) >>> uy array([[ 1. , 0.5 , 0.33333334, 0.25 , 0.2 , 0.16666667, 0.14285715, 0.125 , 0.11111111, 0.1 , 0.09090909, 0.08333334, 0.07692308, 0.07142857, 0.06666667, 0.0625 , 0.05882353, 0.05555556, 0.05263158, 0.05 ], [ 2. , 1. , 0.66666669, 0.5 , 0.40000001, 0.33333334, 0.2857143 , 0.25 , 0.22222222, 0.2 , 0.18181819, 0.16666667, 0.15384616, 0.14285715, 0.13333334, 0.125 , 0.11764706, 0.11111111, 0.10526316, 0.1 ], [ 3. , 1.5 , 1. , 0.75 , 0.60000002, 0.5 , 0.42857143, 0.375 , 0.33333334, 0.30000001, 0.27272728, 0.25 , 0.23076923, 0.21428572, 0.2 , 0.1875 , 0.17647059, 0.16666667, 0.15789473, 0.15000001], [ 4. , 2. , 1.33333337, 1. , 0.80000001, 0.66666669, 0.5714286 , 0.5 , 0.44444445, 0.40000001, 0.36363637, 0.33333334, 0.30769232, 0.2857143 , 0.26666668, 0.25 , 0.23529412, 0.22222222, 0.21052632, 0.2 ], [ 5. , 2.5 , 1.66666663, 1.25 , 1. , 0.83333331, 0.71428573, 0.625 , 0.55555558, 0.5 , 0.45454547, 0.41666666, 0.38461539, 0.35714287, 0.33333334, 0.3125 , 0.29411766, 0.27777779, 0.2631579 , 0.25 ], [ 6. , 3. , 2. , 1.5 , 1.20000005, 1. , 0.85714287, 0.75 , 0.66666669, 0.60000002, 0.54545456, 0.5 , 0.46153846, 0.42857143, 0.40000001, 0.375 , 0.35294119, 0.33333334, 0.31578946, 0.30000001], [ 7. , 3.5 , 2.33333325, 1.75 , 1.39999998, 1.16666663, 1. , 0.875 , 0.77777779, 0.69999999, 0.63636363, 0.58333331, 0.53846157, 0.5 , 0.46666667, 0.4375 , 0.41176471, 0.3888889 , 0.36842105, 0.34999999], [ 8. , 4. , 2.66666675, 2. , 1.60000002, 1.33333337, 1.14285719, 1. , 0.8888889 , 0.80000001, 0.72727275, 0.66666669, 0.61538464, 0.5714286 , 0.53333336, 0.5 , 0.47058824, 0.44444445, 0.42105263, 0.40000001], [ 9. , 4.5 , 3. , 2.25 , 1.79999995, 1.5 , 1.28571427, 1.125 , 1. , 0.89999998, 0.81818181, 0.75 , 0.69230771, 0.64285713, 0.60000002, 0.5625 , 0.52941179, 0.5 , 0.47368422, 0.44999999], [ 10. , 5. , 3.33333325, 2.5 , 2. , 1.66666663, 1.42857146, 1.25 , 1.11111116, 1. , 0.90909094, 0.83333331, 0.76923078, 0.71428573, 0.66666669, 0.625 , 0.58823532, 0.55555558, 0.52631581, 0.5 ]]) >>> p array([[ 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21.], [ 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22.], [ 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23.], [ 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24.], [ 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25.], [ 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26.], [ 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27.], [ 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28.], [ 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28., 29.], [ 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28., 29., 30.]]) Note that you have to provide the shape information for ux and uy because fortran writes them together as a stream of 400 numbers. -Neil [View Less]

10 10

Why does fancy indexing work like this?
by Aaron Meurer Aug. 24, 2020

Aug. 24, 2020

Why does fancy indexing have this behavior? >>> a = np.empty((0, 1, 2)) >>> b = np.empty((1, 1, 2)) >>> a[np.array([10, 10])] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: index 10 is out of bounds for axis 0 with size 0 >>> a[:, np.array([10, 10])] array([], shape=(0, 2, 2), dtype=float64) >>> a[:, :, np.array([10, 10])] array([], shape=(0, 1, 2), dtype=float64) >>> b[np.array([10, 10])] … [View More]

2 12

What is up with raw boolean indices (like a[False])?
by Aaron Meurer Aug. 20, 2020

Aug. 20, 2020

I've been trying to figure out this behavior. It doesn't seem to be documented at https://numpy.org/doc/stable/reference/arrays.indexing.html >>> a = np.empty((2, 3)) >>> a.shape (2, 5) >>> a[True].shape (1, 2, 5) >>> a[False].shape (0, 2, 5) It seems like indexing with a raw boolean (True or False) adds an axis with a dimension 1 or 0, resp. Except it only works once: >>> a[:,False] array([], shape=(2, 0, 3), dtype=float64) >>> a[:,… [View More]

2 11

a summary function to get a quick glimpse on the contents of a numpy array
by Peter Steinbach Aug. 1, 2020

Aug. 1, 2020

Dear numpy devs and interested readers, as a day-to-day user, it occurred to me that having a quick look into the contents and extents of arrays is well doable with numpy. numpy offers a rich set of methods for this. However, very often I oversee myself and others that one just wants to see if the values of an array have a certain min/max or mean or how wide the range of values are. I hence sat down to write a summary function that returns a string of hand-packed summary statistics for a … [View More]quick inspection. I propose to include it into numpy and would love to have your feedback on this idea before I submit a PR. Here is the core functionality: Examples -------- >>> a = np.random.normal(size=20) >>> print(summary(a)) min 25perc mean stdev median 75perc max -2.289870 -2.265757 -0.083213 1.115033 -0.162885 -2.217532 1.639802 >>> a = np.reshape(a, newshape=(4,5)) >>> print(summary(a,axis=1)) min 25perc mean stdev median 75perc max 0 -0.976279 -0.974090 0.293003 1.009383 0.466814 -0.969712 1.519695 1 -0.468854 -0.467739 0.184139 0.649378 -0.036762 -0.465510 1.303144 2 -2.289870 -2.276455 -0.324450 1.230031 -0.289008 -2.249625 1.111107 3 -1.782239 -1.777304 -0.485546 1.259598 -1.236190 -1.767434 1.639802 So you see, it is merely a tiny helper function that can aid practitioners and data scientists to get a quick insight on what an array contains. first off, here is the code: https://github.com/psteinb/numpy/blob/summary-function/numpy/lib/utils.py#L… I put it there as I am not sure at this point, if the community would appreciate such a function or not. Judging from the tests, lib/utils.py appears to a be place for undocumented functions. So to resolve this and prepare a proper PR, please let me know where this summary function could reside! Second, please give me your thoughts on the summary function's output? Should the number of digits be configurable? Should the columns be configurable? Is is ok to honor the axis parameter which is found in so many numpy functions? Last but not least, let me stress that this is my first time contribution to numpy. I love the library and would like to contribute something back. So bear with me, if my code violates best practices in your community for now. I'll bite my teeth into the formalities of a github PR once I get support from the community and the core devs. I think that a summary function would be a valuable addition to numpy! Best, Peter [View Less]

2 1

Re: [Numpy-discussion] Documentation Team meeting - Monday August 3
by Melissa Mendonça July 31, 2020

July 31, 2020

Thanks, you too! On Fri, Jul 31, 2020 at 12:21 PM olzhas robo.ai <o(a)roboai.net> wrote: > Thank you, Melissa! Have a great weekend :) > > On Fri, 31 Jul 2020 at 13:10, Melissa Mendonça <melissawm(a)gmail.com> > wrote: > >> Hi all! >> >> This is a reminder that our next Documentation Team meeting will be on *Monday, >> August 3* at 3PM UTC**. If you wish to join on Zoom, you need to use >> this link >> >> https://zoom.us/j/… [View More]

1 0

NumPy Development Meeting Today - Triage Focus
by Warren Weckesser July 29, 2020

July 29, 2020

Hi all, Sorry for the short notice--Sebastian is off this week, and the rest of us forgot to send the email reminder. Our bi-weekly triage-focused NumPy development meeting is in 10 minutes (today, Wednesday, July 29th, at 11 am Pacific Time (18:00 UTC)). Everyone is invited to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg I encourage everyone to notify us of issues or PRs that you feel should be prioritized or simply discussed … [View More]

1 0

NumPy dtype API improvement suggestion
by Eyal Kutz July 27, 2020

July 27, 2020

I am interested in suggesting an API improvement for NumPy. I wish to make it so that the following code: @np.dtype class Point: x: np.int16 y: np.int16 would be equivalent to the following code: Point = np.dtype([('x', np.int16), ('y', np.int16)]) I am willing to submit the code changes required to make this happen.

4 3

Journey with NumPy in Docs Development
by Saber Tooth July 27, 2020

July 27, 2020

Hello @Melissa Mendonça <melissawm(a)gmail.com> @Ralf Gommers <ralf.gommers(a)gmail.com> @Matti Picus <matti.picus(a)gmail.com> , My journey working with NumPy Docs team has been nothing short of Progressive , the insights that i have gained attending the Docs meeting has helped me refine my proposal . Attending the past 3 meetings have helped me remove some of redundant features in my proposal , letting me structure the Explanations , How-To's ,Tutorials in a better way … [View More]

1 0

Re: [Numpy-discussion] NumPy dtype API improvement suggestion
by Eyal Kutz July 26, 2020

July 26, 2020

*Kevin Sheppard, I agree with you but* I don't know how to do this. do you?

1 0

ANN: SciPy 1.5.2
by Tyler Reddy July 23, 2020

July 23, 2020

Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.5.2, which is a bug fix release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.5.2 One of a few ways to install this release with pip: pip install scipy==1.5.2 ========================== SciPy 1.5.2 Release Notes ========================== SciPy 1.5.2 is a bug-fix release with no new features compared to 1.5.1. … [View More]

1 0

NumPy 1.19.1 released.
by Charles R Harris July 21, 2020

July 21, 2020

Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.19.1 has been released. This release supports Python 3.6-3.8 and may be built with the latest Python 3.9 beta. It fixes several bugs found in the 1.19.0 release, replaces several functions deprecated in the upcoming Python-3.9 release, has improved support for AIX, and has a number of development related updates to keep CI working with recent upstream changes. Downstream developers should use Cython >= 0.29.21 when … [View More]building for Python 3.9 and Cython >= 0.29.16 when building for Python 3.8. OpenBLAS >= 3.7 is needed to avoid wrong results on the Skylake architecture. The NumPy Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/1.19.1/>, source archives, release notes, and wheel hashes are available from Github <https://github.com/numpy/numpy/releases/tag/v1.19.1>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 15 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Abhinav Reddy + - Anirudh Subramanian - Antonio Larrosa + - Charles Harris - Chunlin Fang - Eric Wieser - Etienne Guesnet + - Kevin Sheppard - Matti Picus - Raghuveer Devulapalli - Roman Yurchak - Ross Barnowski - Sayed Adel - Sebastian Berg - Tyler Reddy *Pull requests merged* A total of 25 pull requests were merged for this release. - #16649: MAINT, CI: disable Shippable cache - #16652: MAINT: Replace PyUString_GET_SIZE with PyUnicode_GetLength. - #16654: REL: Fix outdated docs link - #16656: BUG: raise IEEE exception on AIX - #16672: BUG: Fix bug in AVX complex absolute while processing array of... - #16693: TST: Add extra debugging information to CPU features detection - #16703: BLD: Add CPU entry for Emscripten / WebAssembly - #16705: TST: Disable Python 3.9-dev testing. - #16714: MAINT: Disable use_hugepages in case of ValueError - #16724: BUG: Fix PyArray_SearchSorted signature. - #16768: MAINT: Fixes for deprecated functions in scalartypes.c.src - #16772: MAINT: Remove unneeded call to PyUnicode_READY - #16776: MAINT: Fix deprecated functions in scalarapi.c - #16779: BLD, ENH: Add RPATH support for AIX - #16780: BUG: Fix default fallback in genfromtxt - #16784: BUG: Added missing return after raising error in methods.c - #16795: BLD: update cython to 0.29.21 - #16832: MAINT: setuptools 49.2.0 emits a warning, avoid it - #16872: BUG: Validate output size in bin- and multinomial - #16875: BLD, MAINT: Pin setuptools - #16904: DOC: Reconstruct Testing Guideline. - #16905: TST, BUG: Re-raise MemoryError exception in test_large_zip's... - #16906: BUG, DOC: Fix bad MPL kwarg. - #16916: BUG: Fix string/bytes to complex assignment - #16922: REL: Prepare for NumPy 1.19.1 release Cheers, Charles Harris [View Less]

1 0

NumPy Community Meeting Wednesday
by Sebastian Berg July 21, 2020

July 21, 2020

Hi all, There will be a NumPy Community meeting Wednesday July 22nd at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 0

Augment unique method
by Amin Sadeghi July 16, 2020

July 16, 2020

It would be handy to add "atol" and "rtol" optional arguments to the "unique" method. I'm proposing this since uniqueness is a bit vague for floats. This change would be clearly backwards-compatible.

4 4

Discussion around How-to ,Tutorials.
by Saber Tooth July 16, 2020

July 16, 2020

Hello Melissa , Are we having our Docs meeting on 20th July ? If yes , then could we have some discussion around the structure of tutorials ,how-to sections . I wanted to discuss how we are planning to distinguish between the two , should the How-to be straightforward solutions like here <https://matplotlib.org/3.2.2/gallery/lines_bars_and_markers/bar_stacked.htm…> or something else . Tutorials should be structured as in here <https://matplotlib.org/3.2.2/tutorials/introductory/usage.… [View More]

2 1

An alternative to vectorize that lets you access the array?
by Ram Rachum July 15, 2020

July 15, 2020

Hi everyone, Here's a problem I've been dealing with. I wonder whether NumPy has a tool that will help me, or whether this could be a useful feature request. In the upcoming EuroPython 20200, I'll do a talk about live-coding a music synthesizer. It's going to be a fun talk, I'll use the sounddevice <https://github.com/spatialaudio/python-sounddevice/> module to make a program that plays music. Do attend, or watch it on YouTube when it's out :) There's a part in my talk that I could … [View More]

4 6

NumPy Development Meeting Today - Triage Focus
by Sebastian Berg July 15, 2020

July 15, 2020

Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, July 15th) at 11 am Pacific Time (18:00 UTC). Everyone is invited to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg I encourage everyone to notify us of issues or PRs that you feel should be prioritized or simply discussed briefly. Just comment on it so we can label it, or add your PR/issue to this weeks topics for discussion. Best regards Sebastian

1 0

Numpy FFT normalization options issue (addition of new option)
by cvav July 12, 2020

July 12, 2020

Issue #16126: https://github.com/numpy/numpy/issues/16126 PR #16476: https://github.com/numpy/numpy/pull/16476 numpy.fft docs (v1.18): https://numpy.org/doc/1.18/reference/routines.fft.html Hello all, I was advised to write on the numpy mailing list, after this week's community meeting led to some general discussions on the normalization schemes used in the FFT functions. My post has to do with issue #16126, which asks for the addition of a new option for the "norm" argument for the FFT … [View More]

10 14

Collection of Questions for Explanations
by Saber Tooth July 11, 2020

July 11, 2020

Hi Mentors , In the last Docs meeting , we discussed about Explanations and ways we could use to gather relevant topics for which we could provide explanations . The light was shed upon mining of questions firstly from numpy communities via Discussion like groups , then move to other sources . We can mine such topics from the NumPy community via mining email threads of numpy-discussion(a)python.org for Questions . Apart from doing this I am thinking of opening an issue , the track of which … [View More]

2 3

NumPy Sprint on the weekend
by Sebastian Berg July 10, 2020

July 10, 2020

Hi all, since there is the SciPy sprints going on we will also be joining the event and sprinting as well. The kickoff for the SciPy sprint session is at 9:00 CST (7:00 PST, 16:00 CET), with the start of the sprints around 9:30. We are gathering all information at the hackmd: https://hackmd.io/r4pcf4CQRMOUY2VXOWk5_Q so that we can be flexible with organization (e.g. which video software to use). Note that attendance may pick up only a few hours later, but we will try to be around most of … [View More]

1 0

NumPy Documentation Gallery structure
by Saber Tooth July 8, 2020

July 8, 2020

Hello Melissa and Ralf , I was just wondering if we haven't had much discussion on the structuring of tutorials , while we have had some discussion on Explanations . I have been analysing the Tutorials of some other communities too , say Matplotlib : they have basically structured the tutorials page like a Gallery where examples have been arranged in the order of experience level . Link to Matplotlib tutorials : https://matplotlib.org/3.2.2/tutorials/index.html Here is SunPy Documentation. … [View More]

3 3

NumPy Community Meeting Wednesday
by Sebastian Berg July 7, 2020

July 7, 2020

Hi all, There will be a NumPy Community meeting Wednesday July 8th at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 0

GSoD application technical limitations
by Saber Tooth July 7, 2020

July 7, 2020

Hello Melissa , Today I was writing my GSoD proposal application , while I tried to copy / paste my exact Google docs proposal in the application description , but even after clearing all the formatting , the application form is stating that the " response is too large , try shortening some answers " Now many people have complained regarding this issue on the season of docs channel , so it means the issue is upsetting everyone . So I wanted to request if it's fine I also mention the link to … [View More]

2 1

Parlez-vous français?
by Inessa Pawson July 6, 2020

July 6, 2020

As most of you know, the inaugural NumPy community survey <https://umdsurvey.umd.edu/jfe/form/SV_8bJrXjbhXf7saAl> is currently underway. Fabrice Silva kindly offered his help to translate the survey questionnaire into French to maximize the participation of NumPy users and developers from the French-speaking countries. He has already completed his part of the translation (in less than 24 hours!). We are looking for another French-speaking volunteer to finalize the translation process of … [View More]

1 0

ANN: SciPy 1.5.1
by Tyler Reddy July 4, 2020

July 4, 2020

Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.5.1, which is a bug fix release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.5.1 One of a few ways to install this release with pip: pip install scipy==1.5.1 ========================== SciPy 1.5.1 Release Notes ========================== SciPy 1.5.1 is a bug-fix release with no new features compared to 1.5.0. … [View More]In particular, an issue where DLL loading can fail for SciPy wheels on Windows with Python 3.6 has been fixed. Authors ======= * Peter Bell * Loïc Estève * Philipp Thölke + * Tyler Reddy * Paul van Mulbregt * Pauli Virtanen * Warren Weckesser A total of 7 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Issues closed for 1.5.1 -------------------------------- * `#9108 <https://github.com/scipy/scipy/issues/9108>`__: documentation: scipy.spatial.KDTree vs. scipy.spatial.cKDTree * `#12218 <https://github.com/scipy/scipy/issues/12218>`__: Type error in stats.ks_2samp when alternative != 'two-sided- * `#12406 <https://github.com/scipy/scipy/issues/12406>`__: DOC: Docstring in stats.anderson function not properly formatted * `#12418 <https://github.com/scipy/scipy/issues/12418>`__: Regression in hierarchy.dendogram Pull requests for 1.5.1 -------------------------------- * `#12280 <https://github.com/scipy/scipy/pull/12280>`__: BUG: Fixes gh-12218, TypeError converting int to float inside... * `#12336 <https://github.com/scipy/scipy/pull/12336>`__: BUG: KDTree should reject complex input points * `#12344 <https://github.com/scipy/scipy/pull/12344>`__: MAINT: Don't use numpy's aliases of Python builtin objects. * `#12407 <https://github.com/scipy/scipy/pull/12407>`__: DOC: Fix docstring for dist param in anderson function * `#12410 <https://github.com/scipy/scipy/pull/12410>`__: CI: Run the Azure Windows Python36 32bit tests with mode 'fast' * `#12421 <https://github.com/scipy/scipy/pull/12421>`__: Fix regression in scipy 1.5.0 in dendogram when labels is a numpy... * `#12462 <https://github.com/scipy/scipy/pull/12462>`__: MAINT: move distributor_init import after __config__ import Checksums ========= MD5 ~~~ b71e8115d61c604cc65e5ecc556131f6 scipy-1.5.1-cp36-cp36m-macosx_10_9_x86_64.whl 0190c11f75ed28a7e56050182ca95a18 scipy-1.5.1-cp36-cp36m-manylinux1_i686.whl c4dd717a3a0c3fe64380039e4fda663f scipy-1.5.1-cp36-cp36m-manylinux1_x86_64.whl baad02c954e85e7fd3d4a9fd49fc6359 scipy-1.5.1-cp36-cp36m-win32.whl 9edc3a9aedf6bffccb17101c905126d0 scipy-1.5.1-cp36-cp36m-win_amd64.whl 83479a6de66a6bc2da0990fa71cf3cec scipy-1.5.1-cp37-cp37m-macosx_10_9_x86_64.whl f2d5c8713b087545c5ec19cc8e46212c scipy-1.5.1-cp37-cp37m-manylinux1_i686.whl 6a18a9636342574ae55d3a80136c550c scipy-1.5.1-cp37-cp37m-manylinux1_x86_64.whl 5da68faf5b32c539d1cb5390df010cc8 scipy-1.5.1-cp37-cp37m-win32.whl 2ca8c59a6712e91ac78b8540ab694b53 scipy-1.5.1-cp37-cp37m-win_amd64.whl cceb059d0cf6a70e62452deb5571ba00 scipy-1.5.1-cp38-cp38-macosx_10_9_x86_64.whl 8a65b30ccd72409704d3300922da2b7f scipy-1.5.1-cp38-cp38-manylinux1_i686.whl 00181f52a7917d1c3d50e42a76a6df96 scipy-1.5.1-cp38-cp38-manylinux1_x86_64.whl 2aa8b6ddceaebe7b33d71dbad0e208cc scipy-1.5.1-cp38-cp38-win32.whl a626585d08b0991c8f2df0caacdf9997 scipy-1.5.1-cp38-cp38-win_amd64.whl f6986798b7d22ffc5f80b749d7ec27ca scipy-1.5.1.tar.gz e126a1a0ff954b924a8273faa7437fe3 scipy-1.5.1.tar.xz 3bce82b23d45d1a96ee270f23176746a scipy-1.5.1.zip SHA256 ~~~~~~ 058e84930407927f71963a4ad8c1dc96c4d2d075636a68578195648c81f78810 scipy-1.5.1-cp36-cp36m-macosx_10_9_x86_64.whl 7908c85854c5b5b6d3ce7fefafac1ca3e23ff9ac41edabc2d46ae5dc9fa070ac scipy-1.5.1-cp36-cp36m-manylinux1_i686.whl 8302d69fb1528ea7c7f2a1ea640d354c981b6eb8192d1c175349874209397604 scipy-1.5.1-cp36-cp36m-manylinux1_x86_64.whl 35d042d6499caf1a5d171baed0ebf01eb665b7af2ad98a8ff1b0e6e783654540 scipy-1.5.1-cp36-cp36m-win32.whl 5e0bb43ff581811ab7f27425f6b96c1ddf7591ccad2e486c9af0b910c18f7185 scipy-1.5.1-cp36-cp36m-win_amd64.whl b4858ccbd88f4b53950fb9fc0069c1d9fea83d7cff2382e1d8b023d3f4883014 scipy-1.5.1-cp37-cp37m-macosx_10_9_x86_64.whl eb46d8b5947ca27b0bc972cecfba8130f088a83ab3d08c1a6033d9070b3046b3 scipy-1.5.1-cp37-cp37m-manylinux1_i686.whl fff15df01bef1243468be60c55178ed7576270b200aab08a7ffd5b8e0bbc340c scipy-1.5.1-cp37-cp37m-manylinux1_x86_64.whl 81859ed3aad620752dd2c07c32b5d3a80a0d47c5e3813904621954a78a0ae899 scipy-1.5.1-cp37-cp37m-win32.whl c05c6fe76228cc13c5214e9faf5f2a871a1da54473bc417ab9da310d0e5fff8b scipy-1.5.1-cp37-cp37m-win_amd64.whl 71742889393a724dfce755b6b61228677873d269a4234e51ddaf08b998433c91 scipy-1.5.1-cp38-cp38-macosx_10_9_x86_64.whl 9323d268775991b79690f7b9a28a4e8b8c4f2b160ed9f8a90123127314e2d3c1 scipy-1.5.1-cp38-cp38-manylinux1_i686.whl 06b19a650471781056c1a2172eeeeb777b8b516e9434005dd392a4559e0938b9 scipy-1.5.1-cp38-cp38-manylinux1_x86_64.whl 57a0f2be3063dbe1e3daf31ec9005576e8fd1022a28159d0db71d14566899d16 scipy-1.5.1-cp38-cp38-win32.whl c06e731aa46c0dfc563cc636155758178ebc019ef78b9b0f4370effe2ac0f0e6 scipy-1.5.1-cp38-cp38-win_amd64.whl 039572f0ca9578a466683558c5bf1e65d442860ec6e13307d528749cfe6d07b8 scipy-1.5.1.tar.gz 0728bd66a5251cfeff17a72280ae5a40ec14add217f94868d1415b3c469b610a scipy-1.5.1.tar.xz 6dfa9d1e718588f48731e865674b3270130f7736d6c7dc5ceaeb048f55ed793a scipy-1.5.1.zip [View Less]

1 0

reseed random generator (1.19)
by Neal Becker July 4, 2020

July 4, 2020

Consider the following: from numpy.random import default_rng rs = default_rng() Now how do I re-seed the generator? I thought perhaps rs.bit_generator.seed(), but there is no such attribute. Thanks, Neal -- *Those who don't understand recursion are doomed to repeat it*

5 16

Google Summer of Docs Faq and Tutorial Proposed Structure .
by Ben Nathanson July 4, 2020

July 4, 2020

Let me first say I'm a volunteer and not a member of the group that will evaluate proposals. But I can tell you how I would choose. A right-sized proposal is stronger than an overambitious one. I'd scale back and pick a single target. From your listed experience, this would be your first significant docs work. Before you can overhaul an entire site, you need to get a feel for the pace of the work. The review process alone guarantees the site can't be transformed in three months. For argument'… [View More]

1 1

Re: [Numpy-discussion] Help us to make NumPy better
by Inessa Pawson July 3, 2020

July 3, 2020

On Fri, Jul 3, 2020 at 5:45 PM <numpy-discussion-request(a)python.org> wrote: > > ---------- Forwarded message ---------- > From: Inessa Pawson <albuscode(a)gmail.com> > To: numpy-discussion(a)python.org > Cc: > Bcc: > Date: Fri, 3 Jul 2020 12:12:00 +1000 > Subject: [Numpy-discussion] Help us to make NumPy better > > Yes, it’s a survey. But it’s very important. > > Having limited human and financial resources is a common challenge for > open … [View More]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 17th. Click > here <https://umdsurvey.umd.edu/jfe/form/SV_8bJrXjbhXf7saAl> to get > started. > > Inessa Pawson > > NumPy Survey Team > Thank you to everyone who took the time to participate in the inaugural NumPy community survey in the first 24 hours! It is an effort of a group of volunteers who showed a remarkable dedication to the project amidst the COVID-19 pandemic. I’d like to take this opportunity to acknowledge everyone involved. Survey team (in alphabetical order) Ross Barnowski Sebastian Berg Xiaoyi Deng Ralf Gommers Stephanie Mendoza Inessa Pawson Translations team (in alphabetical order) Yuki Dunn Kiko Correoso Garcia Jose Guzman Paul Ivanov Siddhartha Kapoor Tetsuo Koyama Guilherme Leobas Dayane Machado Mahfuza Humayra Mohona Aerik Pawson Zijie Poh Sumera Priyadarsini Shaloo Shalini Kriti Singh Alexandre de Siqueira Special thanks Prof. Frederick Conrad (Survey Research Center, Institute for Social Research, University of Michigan) Prof. Jim Lepkowski (Survey Research Center, Institute for Social Research, University of Michigan) Prof. Michael Traugott (Survey Research Center, Institute for Social Research, University of Michigan) Deji Suolang Mame Fatou Thiam -- Every good wish, *Inessa Pawson* Albus Code inessa(a)albuscode.org [View Less]

1 0

Re: [Numpy-discussion] Google Summer of Docs Faq and Tutorial Proposed Structure .
by Saber Tooth July 3, 2020

July 3, 2020

Hi Melissa , I have been trying to follow https://numpy.org/devdocs/dev/index.html and build docs , i am not able to execute the building albeit following the exact guidelines. Is there a slack channel for this as i'd be able to better explain / resolve it there , till then : I have tried make html command after adhering to the above link Error when i haven't switched it to required git version : installed numpy 32f514f546 != current repo git version '3cf4c28906' use "make dist" or "GITVER=… [View More]32f514f546 make html ..." Makefile:93: recipe for target 'version-check' failed make: *** [version-check] Error 1 Now when i make it work as per my installed numpy version : There are quite a lot of warnings and many problems like : document isn't included in any toctree failed to import 'numpy.polynomial.set_default_printstyle': no module named numpy.polynomial.set_default_printstyle WARNING: autodoc: failed to import module 'typing' from module 'numpy'; the following exception was raised: No module named 'numpy.typing' Many modules were missing which gave a warning , Now maybe the errors are coming in just my workspace , but I have tried reinstalling everything , got the latest version of cython too . It would be really helpful for me if you are able to give me some advice , or a workaround for the problem On Fri, 26 Jun 2020 at 01:39, Melissa Mendonça <melissawm(a)gmail.com> wrote: > Hello Mrinal, > > I don't think I have any other specific issues to comment on your > proposal. The mentors will analyze all proposals after July 9th. > > If you want to start contributing to the docs, you are welcome. You can > check the Contributor Guide (https://numpy.org/devdocs/dev/index.html), > How to contribute documentation ( > https://numpy.org/devdocs/dev/howto-docs.html) and the current > documentation. > > Thanks, > > Melissa > > On Thu, Jun 25, 2020 at 2:27 PM Saber Tooth <sabertooth2022(a)gmail.com> > wrote: > >> Hello Melissa , >> I have altered and built upon my previous proposal , if you could take a >> few minutes to read it it would be great . I have tried to explain the >> sections we had discussed in the meeting on 22 June . >> >> Moreover as per your feedback , I would like to start contributing to the >> docs and start building the docs in my Linux environment . >> >> Best , >> Mrinal Tyagi >> >> >> On Wed, 24 Jun 2020 at 2:36 PM, Saber Tooth <sabertooth2022(a)gmail.com> >> wrote: >> >>> Hello Melissa and all the Mentors , >>> >>> In the last meeting of NumPy Docs held on June 22nd , I had Proposed >>> Tutorial and Faqs structure , where it was discussed how we should include >>> them in the new structured Documentation . >>> Now after a lot of Googling I have been able to provide a >>> structured solution >>> It is very important for us to include the FAQs section , but why ? >>> If we see how many views some questions on Stack overflow >>> https://stackoverflow.com/questions/tagged/numpy?tab=frequent&page=1&pagesi… >>> have got the answer is obvious , the 1st page itself has garnered some 4-5 *million >>> *views and there are really many questions . It means if we are able to >>> answer some of these questions ,not necessarily the exact questions , it >>> would be really good for the Docs . >>> >>> I have tried to break the FAQs page into sections so that everything is >>> not cramped onto one page and we have good docs as per SEO guidelines . >>> I have structured based on best practices for the FAQs section : >>> https://www.shivarweb.com/9665/faq-page-best-practices/ . >>> >>> I have improved further upon my previous proposal , please have a look. >>> Eagerly waiting @Melissa Mendonça <melissawm(a)gmail.com> @Ralf Gommers >>> <ralf.gommers(a)gmail.com> for your feedback on the same , I would be >>> obliged if you have some ideas which could be incorporated with the same or >>> built upon these . >>> >>> >>> >>> Link to Proposal : >>> https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_H… >>> >>> >>> Link to FAQs Proposed structure : >>> https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_H… >>> >>> Link to Tutorials Proposed structure : >>> https://docs.google.com/document/d/1q-BYO-GqlBIsMizCzjbANORz6OOaC-6oEzuE1_H… >>> >>> Thanks , >>> Mrinal Tyagi >>> >> [View Less]

2 2

Re: [Numpy-discussion] Python for Climate Action session at SciPy'20
by Inessa Pawson July 3, 2020

July 3, 2020

Juan, I’ve scheduled the “Python for Climate Action” session for July 8th at 5 - 6 p.m. CDT. Mark, it would be great if someone from pvlib could moderate it. The networking sessions at SciPy'20 will be hosted in a format similar to unconferences. We will be using Zoom to make it easier for the moderators to oversee their sessions. Don't hesitate to contact me if you have any further questions regarding this session. ---------- Forwarded message ---------- > From: "Dr. Mark Alexander … [View More]

1 0

Proposal to add clause to license prohibiting use by oil and gas extraction companies
by John Preston July 2, 2020

July 2, 2020

Hello all, 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 [1] [2] , … [View More]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 reserves. I propose NumPy's current BSD 3-Clause license be extended to include the following conditions, in line with the Climate Strike License [3] : * The Software may not be used in applications and services that are used for or aid in the exploration, extraction, refinement, processing, or transportation of fossil fuels. * The Software may not be used by companies that rely on fossil fuel extraction 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 this definition; 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 used". Many thanks to all of the contributors who have put so much time and energy into NumPy. ✨ ❤️ 😃 [1] https://github.com/gazprom-neft/petroflow [2] https://github.com/climate-strike/analysis [3] https://github.com/climate-strike/license [View Less]

12 12

Help us to make NumPy better
by Inessa Pawson July 2, 2020

July 2, 2020

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 … [View More]

1 0

Improving Complex Comparison/Ordering in Numpy
by Rakesh Vasudevan July 2, 2020

July 2, 2020

Hi all, 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 implementations. 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 … [View More]between instances of 'complex' and 'complex' # Doing the same in Numpy scalar comparision >> np.array(cnum) > np.array(cnum_two) # Yields False *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)) [(1+2j), (1+3j)] # 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 slow. 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), 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] >>> min(clist) 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 function. Requesting feedback and suggestions on the above. Thank you, Rakesh [View Less]

4 6

Re: [Numpy-discussion] Python for Climate Action session at SciPy'20
by Inessa Pawson July 2, 2020

July 2, 2020

Hi, Juan! 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> > Cc: > Bcc: > Date: Thu, 2 Jul 2020 18:58:11 +… [View More]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 [1] 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. > > Juan. > > [1]: https://twitter.com/SciPyConf/status/1276898138977193984 > > > -- Every good wish, *Inessa Pawson* Albus Code inessa(a)albuscode.org [View Less]

3 2