---
tags: NumPy
---

# 2019-06-05 NumPy Development Meeting

- Join via Zoom at [https://berkeley.zoom.us/j/400054438](https://berkeley.zoom.us/j/400054438), or dial-in through a [local phone number](https://zoom.us/u/adQDmEc1wI).
- [Trello workboard](https://trello.com/b/Azg4fYZH/numpy-at-bids)
- [Previous meetings](https://github.com/BIDS-numpy/docs/tree/master/status_meetings)

**Present:** Stefan, Tyler, Matti, Ralf, Chuck, Sebastian, Matthew Rocklin, Kriti, Hameer, Julian Taylor

## Follow-up from last meeting / discussions

## Topics

- Release note management? [gh-13707](https://github.com/numpy/numpy/issues/13707)
- It seems we would like to try a wiki-style release note like what scipy does. It seems to make sense to have a standard summary format for a PR that gets copy-pasted into the wiki. [skimage release notes script](https://github.com/scikit-image/scikit-image/blob/master/tools/generate_release_notes.py) There is also our changelog.py script in tools which could do more
- Regression with `np.matmul` calling `__array_wrap__` with output result that is a different shape than the input. While `__array_wrap__` was not called for `a = np.matmul(df.T, df)` previously, it is not yet clear to me (mattip) how `a` turned into a `DataFrame`
- Maybe `random` [needs more](https://github.com/numpy/numpy/issues/13685) work, maybe not, not clear yet.
1. Give a way to set entropy (for each program)
2. Provide better way to spawn independend streams
- `rnumpy` idea:
- Create seperate project, which pulls in only the core functionality into a clean namespace
- Methods are a bit trickier, may be possible with fancy subclasses.
- Talk for SciPy2019
- We need to finish the talk
- Sebastian will do the 5-minute NumPy presentation
- 1.17 release upcoming: review PRs/Issues marked with 1.17 milestone
- [NEP template](https://github.com/numpy/numpy/blob/master/doc/neps/nep-template.rst): needs to be updated to encourage better justification of changes, description of scope (motivation section: what, why, for whom, how); Hameer will take a pass
- should we make a table re: overhead of ufuncs, np.ones(), and so on---what's the fastest you can expect to get with modern memory, etc?

## Additional Details

- Tyler -- [weekly working notes](https://workflowy.com/s/june-5-2019/FPjnHcQUv3ypMimy)

- Matti

- Sebastian
- Tried to work on refactoring ufunc resolution with the idea it may simplifier later: https://github.com/seberg/numpy/tree/no-ops-in-type-resolution (very much work in progress)
- Old branch with thinking about UfuncImpl to put it out there: https://github.com/seberg/numpy/tree/ufunc-dispatch

---

Please remember to archive this file and commit it to github.com:bids-numpy/docs