Mailman 3 November 2021 - NumPy-Discussion

Putting in `np.ma.ndenumerate` MaskedArray specific ndenumerate
by Sebastian Berg 30 Nov '21

30 Nov '21

Hi all, the `np.ndenumerate` does not work well for masked arrays (like many main namespace functions, it simply ignores/drops the mask). There is a PR (https://github.com/numpy/numpy/pull/20020) to add a version of it to `np.ma` (masked array specific). And we thought it seemed reasonable and were planning on putting it in. This version skips all masked elements. An alternative could be to return `np.ma.masked` for masked elements? So if anyone thinks that may be the better solution, please send a brief mail. (Personally, I don't have opinions on masked arrays for the most part.) Cheers, Sebastian

4 6

Allow for callable in indexing
by cameron.pinnegar＠gmail.com 29 Nov '21

29 Nov '21

If you have an array built up out of method chaining, sometimes you need to filter it at the very end. This can be annoying because it means you have to create a temporary variable just so you can refer to it in the indexing square brackets: _temp = long_and_complicated_expression() result = _temp[_temp >= 0] You could also use the walrus operator but this is odd looking and it still pollutes the namespace: result = (_temp := long_and_complicated_expression())[_temp >= 0] What I would like is to be able to use a lambda inside the indexing square brackets, which would take the whole array as an argument and give a boolean array: result = long_and_complicated_expression()[lambda arr: arr >= 0] I should emphasize, the lambda gets the entire array as its argument, and returns an entire mask array of bools. It isn't like the `map` and `filter` builtins where it would call the python function once for each element and thus be slow. Pandas already has something similar[1]; you can pass a lambda into `.loc[]` that takes a Series and returns a boolean indexer. [1] https://pandas.pydata.org/pandas-docs/version/0.18.1/whatsnew.html#method-c…

4 3

Proposal - Making ndarray object JSON serializable via standardized JData annotations
by Qianqian Fang 26 Nov '21

26 Nov '21

Dear numpy developers, I would like to share a proposal on making ndarray JSON serializable by default, as detailed in this github issue: https://github.com/numpy/numpy/issues/20461 briefly, my group and collaborators are working on a new NIH (National Institute of Health) funded initiative - NeuroJSON (http://neurojson.org) - to further disseminate a lightweight data annotation specification (JData <https://github.com/NeuroJSON/jdata/blob/master/JData_specification.md>) among the broad neuroimaging/scientific community. Python and numpy have been widely used <http://neuro.debian.net/_files/nipy-handout.pdf> in neuroimaging data analysis pipelines (nipy, nibabel, mne-python, PySurfer ... ), because N-D array is THE most important data structure used in scientific data. However, numpy currently does not support JSON serialization by default. This is one of the frequently requested features on github (#16432, #12481). We have developed a lightweight python modules (jdata <https://pypi.org/project/jdata/>, bjdata <https://pypi.org/project/bjdata/>) to help export/import ndarray objects to/from JSON (and a binary JSON format - BJData <https://github.com/NeuroJSON/bjdata/blob/master/Binary_JData_Specification.…>/UBJSON <http://ubjson.org/> - to gain efficiency). The approach is to convert ndarray objects to a dictionary with subfields using standardized JData annotation tags. The JData spec can serialize complex data structures such as N-D arrays (solid, sparse, complex). trees, graphs, tables etc. It also permits data compression. These annotations have been implemented in my MATLAB toolbox - JSONLab <https://github.com/fangq/jsonlab> - since 2011 to help import/export MATLAB data types, and have been broadly used among MATLAB/GNU Octave users. Examples of these portable JSON annotation tags representing N-D arrays can be found at http://openjdata.org/wiki/index.cgi?JData/Examples/Basic#2_D_arrays_in_the_… http://openjdata.org/wiki/index.cgi?JData/Examples/Advanced and the detailed formats on N-D array annotations can be found in the spec: https://github.com/NeuroJSON/jdata/blob/master/JData_specification.md#annot… our current python module to encode/decode ndarray to JSON serializable forms are implemented in these compact functions (handling lossless type/data conversion and data compression) https://github.com/NeuroJSON/pyjdata/blob/63301d41c7b97fc678fa0ab0829f76c76… https://github.com/NeuroJSON/pyjdata/blob/63301d41c7b97fc678fa0ab0829f76c76… We strongly believe that enabling JSON serialization by default will benefit the numpy user community, making it a lot easier to share complex data between platforms (MATLAB/Python/C/FORTRAN/JavaScript...) via a standardized/NIH-backed data annotation scheme. We are happy to hear your thoughts, suggestions on how to contribute, and also glad to set up dedicated discussions. Cheers Qianqian

3 5

ANN: SciPy 1.7.3
by Tyler Reddy 24 Nov '21

24 Nov '21

Hi all, On behalf of the SciPy development team, I'm pleased to announced the release of SciPy 1.7.3, which is a bug fix release that includes wheels for MacOS 12+ arm64 at Python versions 3.8, 3.9, and 3.10. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.7.3 <https://github.com/scipy/scipy/releases/tag/v1.6.3> <https://github.com/scipy/scipy/releases/tag/v1.6.1> One of a few ways to install this release with pip: pip install scipy==1.7.3 ===================== SciPy 1.7.3 Release Notes ===================== SciPy 1.7.3 is a bug-fix release that provides binary wheels for MacOS arm64 with Python 3.8, 3.9, and 3.10. The MacOS arm64 wheels are only available for MacOS version 12.0 and greater, as explained in Issue 14688, linked below. Authors ====== * Anirudh Dagar * Ralf Gommers * Tyler Reddy * Pamphile Roy * Olivier Grisel * Isuru Fernando A total of 6 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.7.3 ------------------------------- * `#13364 <https://github.com/scipy/scipy/issues/13364>`__: Segmentation fault on import of scipy.integrate on Apple M1 ARM... * `#14688 <https://github.com/scipy/scipy/issues/14688>`__: BUG: ARPACK's eigsh & OpenBLAS from Apple Silicon M1 (arm64)... * `#14991 <https://github.com/scipy/scipy/issues/14991>`__: four CI failures on pre-release job * `#15077 <https://github.com/scipy/scipy/issues/15077>`__: Remaining test failures for macOS arm64 wheel * `#15081 <https://github.com/scipy/scipy/issues/15081>`__: BUG: Segmentation fault caused by scipy.stats.qmc.qmc.update_discrepancy Pull requests for 1.7.3 ------------------------------ * `#14990 <https://github.com/scipy/scipy/pull/14990>`__: BLD: update pyproject.toml for Python 3.10 changes * `#15086 <https://github.com/scipy/scipy/pull/15086>`__: BUG: out of bounds indexing in stats.qmc.update_discrepancy * `#15090 <https://github.com/scipy/scipy/pull/15090>`__: MAINT: skip a few failing tests in \`1.7.x\` for macOS arm64 Checksums ========= MD5 ~~~ 65166885666a1a74deffe429d093e6f2 scipy-1.7.3-cp310-cp310-macosx_10_9_x86_64.whl 537752d6744b507f203f376ec2df6e70 scipy-1.7.3-cp310-cp310-macosx_12_0_arm64.whl e518125fc38cedde00da54672655b7cd scipy-1.7.3-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl c83ba57d18c24e3e0f899378f6bc0876 scipy-1.7.3-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl ba90233a59aaf0f05485de296bea6fc1 scipy-1.7.3-cp310-cp310-win_amd64.whl ce3ca8d9bb3ace6686b89e07f767a013 scipy-1.7.3-cp37-cp37m-macosx_10_9_x86_64.whl 16ce33be314dae61c953c5c6e605cba6 scipy-1.7.3-cp37-cp37m-manylinux_2_12_i686.manylinux2010_i686.whl 83f8b25f1a00a5e37eca4e1463d046fa scipy-1.7.3-cp37-cp37m-manylinux_2_12_x86_64.manylinux2010_x86_64.whl 44254582f51de14fd15d8be44a309a8b scipy-1.7.3-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl af219af017f220f217e6308cad5893e1 scipy-1.7.3-cp37-cp37m-win32.whl 29b476d691e325c924b2cf77d0ff8b99 scipy-1.7.3-cp37-cp37m-win_amd64.whl 6341d96c9f9edfd7221708636d6dab5c scipy-1.7.3-cp38-cp38-macosx_10_9_x86_64.whl 919b3f6c4b5f9cc137b2e40c50837ba7 scipy-1.7.3-cp38-cp38-macosx_12_0_arm64.whl 697cb8e337a8073792aca67aa4dd7f49 scipy-1.7.3-cp38-cp38-manylinux_2_12_i686.manylinux2010_i686.whl e1c1c129731f8623f7168153f6088472 scipy-1.7.3-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 6203426ffb92a0a12606eaa885d74d54 scipy-1.7.3-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 936de7e1b6c4f05079ac2ea4e63d0436 scipy-1.7.3-cp38-cp38-win32.whl 9da686cd27c2e51342deb1d2d060fa08 scipy-1.7.3-cp38-cp38-win_amd64.whl cf4e152fb2e7241e7bdd7761191590ae scipy-1.7.3-cp39-cp39-macosx_10_9_x86_64.whl 97f2f1ee23139230063ff07ce4e9c61b scipy-1.7.3-cp39-cp39-macosx_12_0_arm64.whl df508267071a08b63f21b8ae3dcd5eb2 scipy-1.7.3-cp39-cp39-manylinux_2_12_i686.manylinux2010_i686.whl 391662df3e0411daa08b5421e54ad9c0 scipy-1.7.3-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 0587d18e903b1ceaeb6bab73f704872d scipy-1.7.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 3a0b4991b3a994fb6e0bbcc9c99ab5c9 scipy-1.7.3-cp39-cp39-win32.whl 4e168ff30d040edbaac53efb43d8cda4 scipy-1.7.3-cp39-cp39-win_amd64.whl daae4fedcd479738e54fd7035445be89 scipy-1.7.3.tar.gz 9e6a6ae20e68e99031229c430f966672 scipy-1.7.3.tar.xz 1a9ceac2a40fef71b75859040e371906 scipy-1.7.3.zip SHA256 ~~~~~~ 173308efba2270dcd61cd45a30dfded6ec0085b4b6eb33b5eb11ab443005e088 scipy-1.7.3-cp310-cp310-macosx_10_9_x86_64.whl 21b66200cf44b1c3e86495e3a436fc7a26608f92b8d43d344457c54f1c024cbc scipy-1.7.3-cp310-cp310-macosx_12_0_arm64.whl ceebc3c4f6a109777c0053dfa0282fddb8893eddfb0d598574acfb734a926168 scipy-1.7.3-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl f7eaea089345a35130bc9a39b89ec1ff69c208efa97b3f8b25ea5d4c41d88094 scipy-1.7.3-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 304dfaa7146cffdb75fbf6bb7c190fd7688795389ad060b970269c8576d038e9 scipy-1.7.3-cp310-cp310-win_amd64.whl 033ce76ed4e9f62923e1f8124f7e2b0800db533828c853b402c7eec6e9465d80 scipy-1.7.3-cp37-cp37m-macosx_10_9_x86_64.whl 4d242d13206ca4302d83d8a6388c9dfce49fc48fdd3c20efad89ba12f785bf9e scipy-1.7.3-cp37-cp37m-manylinux_2_12_i686.manylinux2010_i686.whl 8499d9dd1459dc0d0fe68db0832c3d5fc1361ae8e13d05e6849b358dc3f2c279 scipy-1.7.3-cp37-cp37m-manylinux_2_12_x86_64.manylinux2010_x86_64.whl ca36e7d9430f7481fc7d11e015ae16fbd5575615a8e9060538104778be84addf scipy-1.7.3-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl e2c036492e673aad1b7b0d0ccdc0cb30a968353d2c4bf92ac8e73509e1bf212c scipy-1.7.3-cp37-cp37m-win32.whl 866ada14a95b083dd727a845a764cf95dd13ba3dc69a16b99038001b05439709 scipy-1.7.3-cp37-cp37m-win_amd64.whl 65bd52bf55f9a1071398557394203d881384d27b9c2cad7df9a027170aeaef93 scipy-1.7.3-cp38-cp38-macosx_10_9_x86_64.whl f99d206db1f1ae735a8192ab93bd6028f3a42f6fa08467d37a14eb96c9dd34a3 scipy-1.7.3-cp38-cp38-macosx_12_0_arm64.whl 5f2cfc359379c56b3a41b17ebd024109b2049f878badc1e454f31418c3a18436 scipy-1.7.3-cp38-cp38-manylinux_2_12_i686.manylinux2010_i686.whl eb7ae2c4dbdb3c9247e07acc532f91077ae6dbc40ad5bd5dca0bb5a176ee9bda scipy-1.7.3-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 95c2d250074cfa76715d58830579c64dff7354484b284c2b8b87e5a38321672c scipy-1.7.3-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 87069cf875f0262a6e3187ab0f419f5b4280d3dcf4811ef9613c605f6e4dca95 scipy-1.7.3-cp38-cp38-win32.whl 7edd9a311299a61e9919ea4192dd477395b50c014cdc1a1ac572d7c27e2207fa scipy-1.7.3-cp38-cp38-win_amd64.whl eef93a446114ac0193a7b714ce67659db80caf940f3232bad63f4c7a81bc18df scipy-1.7.3-cp39-cp39-macosx_10_9_x86_64.whl eb326658f9b73c07081300daba90a8746543b5ea177184daed26528273157294 scipy-1.7.3-cp39-cp39-macosx_12_0_arm64.whl 93378f3d14fff07572392ce6a6a2ceb3a1f237733bd6dcb9eb6a2b29b0d19085 scipy-1.7.3-cp39-cp39-manylinux_2_12_i686.manylinux2010_i686.whl edad1cf5b2ce1912c4d8ddad20e11d333165552aba262c882e28c78bbc09dbf6 scipy-1.7.3-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 5d1cc2c19afe3b5a546ede7e6a44ce1ff52e443d12b231823268019f608b9b12 scipy-1.7.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 2c56b820d304dffcadbbb6cbfbc2e2c79ee46ea291db17e288e73cd3c64fefa9 scipy-1.7.3-cp39-cp39-win32.whl 3f78181a153fa21c018d346f595edd648344751d7f03ab94b398be2ad083ed3e scipy-1.7.3-cp39-cp39-win_amd64.whl ab5875facfdef77e0a47d5fd39ea178b58e60e454a4c85aa1e52fcb80db7babf scipy-1.7.3.tar.gz 4042211bed8e6c658b9e2a4ca829806f0b33437faa7878c8dc6d6f72845b1694 scipy-1.7.3.tar.xz 16669af9790fcc64f3a914bc0a1a2025daa5f9a8d2f203bda4214569d59d0916 scipy-1.7.3.zip

1 0

NumPy 1.22.0rc1 released.
by Charles R Harris 23 Nov '21

23 Nov '21

Hi All, On behalf of the NumPy team, I'm pleased to announce the release of NumPy 1.22.0rc1. NumPy 1.22.0rc1 is a big release featuring the work of 150 contributers spread over 575 pull requests. There have been many improvements, highlights are: - Annotations of the main namespace are essentially complete. Upstream is a moving target, so there will likely be further improvements, but the major work is done. This is probably the most user visible enhancement in this release. - A preliminary version of the proposed Array-API is provided. This is a step in creating a standard collection of functions that can be used across applications such as CuPy and JAX. - NumPy now has a DLPack backend. DLPack provides a common interchange format for array (tensor) data. - New methods for `quantile`, `percentile`, and related functions. Thenew methods provide a complete set of the methods commonly found in the literature. - A new configurable allocator for use by downstream projects. These are in addition to the ongoing work to provide SIMD support for commonly used functions, improvements to F2PY, and better documentation. The Python versions supported in this release are 3.8-3.10, Python 3.7 has been dropped. Note that 32 bit wheels are only provided for Python 3.8 and 3.9 on Windows, all other wheels are 64 bits on account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit support. All 64 bit wheels are also linked with 64 bit OpenBLAS, which should fix the occasional problems encountered by folks using truly huge arrays. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.22.0rc1/>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.22.0rc1>. Linux users will need pip >= 0.19.3 in order to install the manylinux2014 wheels. A recent version of pip is needed to install the universal2 macos wheels. *Contributors* A total of 150 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - @DWesl - @Illviljan - @h-vetinari - @yan-wyb + - Aaron Meurer - Abel Aoun + - Adrian Gao + - Ahmet Can Solak + - Ajay DS + - Alban Colley + - Alberto Rubiales + - Alessia Marcolini + - Amit Kumar + - Andrei Batomunkuev + - Andrew Watson + - Anirudh Dagar + - Ankit Dwivedi + - Antony Lee - Arfy Slowy + - Arryan Singh + - Arun Palaniappen + - Arushi Sharma + - Bas van Beek - Brent Brewington + - Carl Johnsen + - Carl Michal + - Charles Harris - Chiara Marmo - Chris Fu (傅立业) + - Christoph Buchner + - Christoph Reiter + - Chunlin Fang - Clément Robert + - Constanza Fierro - Damien Caliste - Daniel Ching - David Badnar + - David Cortes + - David Okpare + - Derek Huang + - Developer-Ecosystem-Engineering + - Dima Pasechnik - Dimitri Papadopoulos + - Dmitriy Fishman + - Eero Vaher + - Elias Koromilas + - Eliaz Bobadilla + - Elisha Hollander + - Eric Wieser - Eskild Eriksen + - Fayas Noushad + - Gagandeep Singh + - Ganesh Kathiresan - Ghiles Meddour + - Greg Lucas - Gregory R. Lee - Guo Shuai + - Gwyn Ciesla + - Hameer Abbasi - Hector Martin + - Henry Schreiner + - Himanshu + - Hood Chatham + - Hugo Defois + - Hugo van Kemenade - I-Shen Leong + - Imen Rajhi + - Irina Maria Mocan + - Irit Katriel + - Isuru Fernando - Jakob Jakobson - Jerry Morrison + - Jessi J Zhao + - Joe Marshall + - Johan von Forstner + - Jonas I. Liechti + - Jonathan Reichelt Gjertsen + - Joshua Himmens + - Jérome Eertmans - Jérôme Kieffer + - KIU Shueng Chuan + - Kenichi Maehashi - Kenny Huynh + - Kent R. Spillner + - Kevin Granados + - Kevin Modzelewski + - Kevin Sheppard - Lalit Musmade + - Malik Idrees Hasan Khan + - Marco Aurelio da Costa + - Margret Pax + - Mars Lee + - Marten van Kerkwijk - Matthew Barber + - Matthew Brett - Matthias Bussonnier - Matthieu Dartiailh - Matti Picus - Melissa Weber Mendonça - Michael McCann + - Mike Jarvis + - Mike McCann + - Mike Toews - Mukulika Pahari - Nick Pope + - Nick Wogan + - Niels Dunnewind + - Niko Savola + - Nikola Forró - Niyas Sait + - Pamphile ROY - Paul Ganssle + - Pauli Virtanen - Pearu Peterson - Peter Hawkins + - Peter Tillema + - Prathmesh Shirsat + - Raghuveer Devulapalli - Ralf Gommers - Robert Kern - Rohit Goswami + - Ronan Lamy - Ross Barnowski - Roy Jacobson + - Samyak S Sarnayak + - Sayantika Banik + - Sayed Adel - Sebastian Berg - Sebastian Schleehauf + - Serge Guelton - Shriraj Hegde + - Shubham Gupta + - Sista Seetaram + - Stefan van der Walt - Stephannie Jimenez Gacha + - Tania Allard - Theodoros Nikolaou + - Thomas J. Fan - Thomas Li + - Tim Hoffmann - Tom Tan + - Tyler Reddy - Vijay Arora + - Vinith Kishore + - Warren Weckesser - Yang Hau - Yashasvi Misra - Yuval Ofek + - Zac Hatfield-Dodds - Zhang Na + Cheers, Charles Harris

1 0

Re: NumPy-Discussion Digest, Vol 182, Issue 36
by David Nicholson 23 Nov '21

23 Nov '21

The solution for not rendering Markdown files already works for .rst files, you append ?plain=1 to the url as in this issue: https://github.com/numpy/numpy/issues/20438 On Tue, Nov 23, 2021, 12:00 PM <numpy-discussion-request(a)python.org> wrote: > Send NumPy-Discussion mailing list submissions to > numpy-discussion(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > or, via email, send a message with subject or body 'help' to > numpy-discussion-request(a)python.org > > You can reach the person managing the list at > numpy-discussion-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NumPy-Discussion digest..." > > Today's Topics: > > 1. Ask GitHub to provide an option to not render .rst files > (Warren Weckesser) > 2. Re: Code formatters (Adrin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 Nov 2021 12:38:41 -0500 > From: Warren Weckesser <warren.weckesser(a)gmail.com> > Subject: [Numpy-discussion] Ask GitHub to provide an option to not > render .rst files > To: Discussion of Numerical Python <numpy-discussion(a)python.org>, > SciPy Developers List <scipy-dev(a)python.org> > Message-ID: > <CAGzF1uegdstOFaK= > AK-m0kKmoRev8CkS6vEAEkoKDv4uze0PDg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hey all, > > If you've ever tried to inspect a file on github with the `.rst` > extension, there's a good chance that you were frustrated by GitHub > providing a rendered view *only* of the file, with no option to view > the source code like any other text file. It is certainly nice to > have a rendered view, but often I want to inspect the actual source > code (e.g. to find out at which line a heading occurs, perhaps to > include a link to it in a pull request). There is the "raw" option, > or you could click "edit", but what is really desired is a view of the > source like any other source code. > > Files with the `.md` extension are also rendered by default, but there > are buttons that allow you to either "Display the source blob" or > "Display the rendered blob". There is no such option for `.rst` files. > If they can do it for `.md` files, it seems like it should be easy to > do the same for `.rst` files. > > I've tried creating a ticket on github about this, but it seems like > tickets go to the wrong group. The response I got was from the > "GitHub Support" team, and they said they forwarded the request to the > "Product" team. (It's all GitHub to me.) It was also suggested that > I bring this up in a public feedback discussions, so I did: > > https://github.com/github/feedback/discussions/7999 > > If you have a moment, could you add a comment, or click the upvote > button, or add some other feedback to the discussion? It would be > nice to get this simple enhancement into the GitHub site. > > Thanks, > > Warren > > ------------------------------ > > Message: 2 > Date: Mon, 22 Nov 2021 23:31:32 +0100 > From: Adrin <adrin.jalali(a)gmail.com> > Subject: [Numpy-discussion] Re: Code formatters > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Message-ID: > < > CAEOrW4-1CVR2+Taffp382GcvsqcESnbEa5_x2zJGN26kUfC+-w(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="00000000000073b9aa05d168305c" > > This discussion and the linked gist may be of some help: > https://github.com/scikit-learn/scikit-learn/issues/11336 > > On Mon, Nov 22, 2021 at 12:02 PM Andrew Nelson <andyfaff(a)gmail.com> wrote: > > > Is there a way to figure out which files are not touched by any open PR? > > That way numpy might be able to do a lot more than an incremental code > > alignment. > > _______________________________________________ > > NumPy-Discussion mailing list -- numpy-discussion(a)python.org > > To unsubscribe send an email to numpy-discussion-leave(a)python.org > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > > Member address: adrin.jalali(a)gmail.com > > >

1 0

Code formatters
by Charles R Harris 22 Nov '21

22 Nov '21

Hi All, This post is for discussing the automatic code formatters for C/C++/*.py that are now available. The current options, as I see them, are clang-format (C/C++) and black (*.py, *.pyi, etc). Neither is perfect to my eye, but I think they are good enough at this point and would reduce amount of style nitpicking. *clang-format* There is already a '.clang-format' file in the numpy repository. The main drawbacks that I see are: - no automatic spacing between function definitions, - all operators, including '*' and '/', get spaces around them, - no extra indenting of continued 'if' conditions, - the order of includes is alphabetical within groups. The groups are currently defined in the 'clang-format' file, but there may still be problems with include order that we will need to fix. I think those can be lived with. The results are good enough that I think it can replace the official C coding style for most things. The maximum line length is currently 79 characters. *black* The black formatter is much improved in its latest version and I think good enough to start using. The main drawbacks that I see are: - all operators, including '*' and '/', get spaces around them, - very long strings are not broken into multiple lines, - lists, tuples, and function signatures are either on one line, or broken into multiple lines of one element/argument each, - the formatting of extended logical expressions could be improved to emphasize the priority of 'and' over 'or' operators There is no current configuration in pyproject.toml, the default maximum line length is 88 characters. I note that setting the line length to 79 notably increases the number of line breaks needed. Note that double quotes are now preferred to single quotes. I think that including black configuration in pyproject.toml would be a good idea, the main question is line length, 79 or 88 characters. The same question of line length can also be raised for clang-format. Lines much longer than 88 are characters are not only a problem for terminals, they are also hard to focus on if you have bad eyes, but lines longer than 79 characters also reduce the number of line breaks needed. Thoughts? Chuck

14 19

Ask GitHub to provide an option to not render .rst files
by Warren Weckesser 22 Nov '21

22 Nov '21

Hey all, If you've ever tried to inspect a file on github with the `.rst` extension, there's a good chance that you were frustrated by GitHub providing a rendered view *only* of the file, with no option to view the source code like any other text file. It is certainly nice to have a rendered view, but often I want to inspect the actual source code (e.g. to find out at which line a heading occurs, perhaps to include a link to it in a pull request). There is the "raw" option, or you could click "edit", but what is really desired is a view of the source like any other source code. Files with the `.md` extension are also rendered by default, but there are buttons that allow you to either "Display the source blob" or "Display the rendered blob". There is no such option for `.rst` files. If they can do it for `.md` files, it seems like it should be easy to do the same for `.rst` files. I've tried creating a ticket on github about this, but it seems like tickets go to the wrong group. The response I got was from the "GitHub Support" team, and they said they forwarded the request to the "Product" team. (It's all GitHub to me.) It was also suggested that I bring this up in a public feedback discussions, so I did: https://github.com/github/feedback/discussions/7999 If you have a moment, could you add a comment, or click the upvote button, or add some other feedback to the discussion? It would be nice to get this simple enhancement into the GitHub site. Thanks, Warren

1 0

CANCELLED: NumPy Community Meeting (typically Wednesday's)
by Sebastian Berg 22 Nov '21

22 Nov '21

Hi all, There is no Community planned this Wednesday, since I am traveling and a few others who typically attend are also on vacation. Best wishes Sebastian

1 0

Call for contributions: 2021 NumPy Community Survey Analysis
by Stephanie Mendoza 21 Nov '21

21 Nov '21

Hello NumPy Community, We are seeking volunteers to help with the analysis of the 2021 NumPy Community Survey data. As a contributor, you will analyze an assigned section of the survey data with the goal of extracting insights to be used in a public analysis report, and/or review the analysis conducted by other contributors. (For reference, see the 2020 NumPy Community Survey final report: https://numpy.org/surveys/NumPy_usersurvey_2020_report.pdf.) This community contribution opportunity is best suited to those who have some experience in statistics, data analysis, visualizations, and report writing. We expect that this task will take approximately 3 hours to complete, with both analysis and reviews to be finalized by December 6th. If you are interested in volunteering, please contact Stephanie Mendoza: stephaniemendoza2014(a)gmail.com

1 0