<commit_before>=============
NumPy Roadmap
=============

This is a live snapshot of tasks and features we will be investing resources
in. It may be used to encourage and inspire developers and to search for
funding.

Interoperability protocols & duck typing
========================================

`__array_function__`
--------------------
See `NEP 18`_ and a sample implementation_

Array Duck-Typing
-----------------
`NEP 22`_    `np.asduckarray()`


Mixins like `NDArrayOperatorsMixin`:

- for mutable arrays
- for reduction methods implemented as ufuncs

Better dtypes
-------------

- Easier custom dtypes
  - Simplify and/or wrap the current C-API
  - More consistent support for dtype metadata
  - Support for writing a dtype in Python
- New string dtype(s):
  - Encoded strings with fixed-width storage (utf8, latin1, ...)
  - Variable length strings (could share implementation with dtype=object, but are explicitly type-checked)
  - One of these should probably be the default for text data. The current behavior on Python 3 is neither efficient nor user friendly.
- `np.int` should not be platform dependent
- better coercion for string + number

Random number generation policy & rewrite
-----------------------------------------

`NEP 19`_ and a `reference implementation`_
<commit_msg>String encoding: increase uncertainty about correct implementation (as per https://mail.python.org/pipermail/numpy-discussion/2018-July/078472.html)<commit_after>=============
NumPy Roadmap
=============

This is a live snapshot of tasks and features we will be investing resources
in. It may be used to encourage and inspire developers and to search for
funding.

Interoperability protocols & duck typing
========================================

`__array_function__`
--------------------
See `NEP 18`_ and a sample implementation_

Array Duck-Typing
-----------------
`NEP 22`_    `np.asduckarray()`


Mixins like `NDArrayOperatorsMixin`:

- for mutable arrays
- for reduction methods implemented as ufuncs

Better dtypes
-------------

- Easier custom dtypes
  - Simplify and/or wrap the current C-API
  - More consistent support for dtype metadata
  - Support for writing a dtype in Python
- New string dtype(s):
  - Encoded strings with fixed-width storage (utf8, latin1, ...) and/or
  - Variable length strings (could share implementation with dtype=object, but are explicitly type-checked)
  - One of these should probably be the default for text data. The current behavior on Python 3 is neither efficient nor user friendly.
- `np.int` should not be platform dependent
- better coercion for string + number

Random number generation policy & rewrite
-----------------------------------------

`NEP 19`_ and a `reference implementation`_

{'fraction_non_alphanumeric': 0.16521106259097526, 'fraction_numerical': 0.010189228529839884, 'mean_word_length': 3.1841704718417048, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2807325', 'n_tokens_mistral': 725, 'n_tokens_neox': 669, 'n_words': 314}