---
tags: NumPy, triage
---

# 2021-05-05 NumPy Development Meeting -- Triage

Note: we alternate between [community meetings](https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg) and triage meetings.

- Time: 11am Pacific Time
- Join via Zoom at https://berkeley.zoom.us/j/762261535 (or [dial-in](https://berkeley.zoom.us/u/aC3ENhycM))
- [Trello workboard](https://trello.com/b/Azg4fYZH/numpy-at-bids)
- [Previous community meetings](https://github.com/numpy/archive/tree/master/status_meetings)
- [Previous triage meetings](https://github.com/numpy/archive/tree/master/triage_meetings)

**Present:** Chuck, Ross, Matti, Abdul-Hameed Tade, Sebastian

## Triage

* [PRs and issues labelled with "Triage-Review"](https://github.com/numpy/numpy/labels/Triage-review) (please add)

* [PRs and issues labeled with "needs decision"](https://github.com/numpy/numpy/labels/54%20-%20Needs%20decision) (50 open)

* [Open PRs (>235 open)](https://github.com/numpy/numpy/pulls) can we get this below 200?

* Ross' list of cross-referenced issues: https://rossbar.github.io/github_graphql/index.html

## Followup

* Quantile methods and weights discussion.
- Weights may not depend on the "methods"
- We should try to resolve the "method" problem, which probably means one of us has to start the deprecation process. The current default and "H&F" should be obvious, beyond that maybe we can wait for new contributors.
- Try to ping @chunweiyuan maybe we can get them to do this step? (Matti will ping, if nothing happens we can discuss again next time)

## Topics

* Shipping 64bit BLAS wheels
* Do it after the branching 1.21, so we get testing on `main`, then plan to change it for the next one.

* Go through the milestoned issues for 1.21. (most of the call)

* Loop resolution: https://github.com/numpy/numpy/pull/18880
- For legacy (but it would be a bit stuck for a while), make `dtype=DType` mean:
* `signature=(None,) * nin + (DType,) * nout`
* But, if `signature=(None,) * nin + (DType,) * nout` does not find a loop, also try `signature=(DType,) * (nin+nout)`
- Upside: perfectly backward compatible (if the first finds a loop, it will be OK, otherwise the second is what we currently try – usually)
- It could be that the second try finds a "not ideal" loop (SciPy has ufuncs with loops `dl->d` and `dd->d` so if the first try fails to match, the second one could match even though the first would be a "better" match. This is very obscure though)
- In the future, we would have to create explicit `promoter` functions for this (some paths that currently work would probably be slowly deprecated/removed when phasing out legacy loops).

* How to get the ufunc rework in: https://github.com/numpy/numpy/pull/18905
* I would really like to be able to put it into the 1.21, hopefully with the "experimental DType branch". Just to get ahead of things a bit and maybe also flush out some problems.
* There is a bit of complexity that may still be in flux, I _hope_ that is OK!
* Right now reduce/accumulate/reduceat and `ufunc.at` are missing: I can manage to add those before the branch without much problem, I think.

---

Please remember to archive this file and commit it to github.com/numpy/archive