Stefan and Ralf -- thanks for finishing this up! I'm quite happy with the state of this. On Tue, Jul 24, 2018 at 1:17 PM Gael Varoquaux < gael.varoquaux@normalesup.org> wrote:

Looks great! Thank you for doing this!

Gaël

On Tue, Jul 24, 2018 at 12:04:49PM -0700, Stefan van der Walt wrote:

...

Hi everyone,

...

Please take a look at the latest roadmap proposal:

...

https://github.com/numpy/numpy/pull/11611

...

This is a living document, so can easily be modified in the future, but we'd like to get in place a document that corresponds fairly closely with current community priorities.

...

Best regards, Stéfan _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

-- Gael Varoquaux Senior Researcher, INRIA Parietal NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France Phone: ++ 33-1-69-08-79-68 <+33%201%2069%2008%2079%2068> http://gael-varoquaux.info http://twitter.com/GaelVaroquaux _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

Great work, thanks! I see this: “- Fixed width encoded strings (utf8, latin1, ...)” And a bit of discussion in the PR. But I think there are key questions to be addressed in handling strings in numpy. I know we’ve had a lot of discussion about it on this list over the years — but is there a place that has captured that discussion / and or we can start a new one? For example, I am very wary of putting a non-fixed width encoding (e.g. Utf-8) in a fixed width field. But this PR is not the place to discuss that. -CHB Sent from my iPhone On Jul 24, 2018, at 3:21 PM, Hameer Abbasi wrote: Hey Stefan/Ralf/Stephan, This looks nice, generally what the community agrees on. Great work, and thanks for putting this together. Best regards, Hameer Abbasi Sent from Astro https://www.helloastro.com for Mac On 24. Jul 2018 at 21:04, Stefan van der Walt wrote: Hi everyone, Please take a look at the latest roadmap proposal: https://github.com/numpy/numpy/pull/11611 This is a living document, so can easily be modified in the future, but we'd like to get in place a document that corresponds fairly closely with current community priorities. Best regards, Stéfan _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

On Wed, Jul 25, 2018 at 4:02 PM Stefan van der Walt wrote:

Hi Chris,

On Wed, 25 Jul 2018 08:13:26 -0700, Chris Barker - NOAA Federal wrote:

...

For example, I am very wary of putting a non-fixed width encoding (e.g. Utf-8) in a fixed width field.

But this PR is not the place to discuss that.

Since you've followed that discussion closely, can you push a commit to my PR with text that more accurately captures the situation?

Thanks! Stéfan

Hi Chris, Obviously the string dtype proposal in the roadmap is only a sketch at this point :). I do think that options listed currently (encoded strings with fixed-width storage and variable length strings) cover the breadth of proposals from last time. We may not want to implement all of them in NumPy, but I think we can agree that there are use cases for all them, even if only as external dtypes? Would it help to add "and/or" after the first bullet? Mostly I care about having like to have "improve string dtypes" in some form on the roadmap, and thought it would be helpful to list the concrete proposals that I recall. The actual design choices (especially if we proposal to change any default behavior) will certainly need a NEP. Best, Stephan

On Thu, Jul 26, 2018 at 12:41 AM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:

...

Obviously the string dtype proposal in the roadmap is only a sketch at this point :).

I do think that options listed currently (encoded strings with fixed-width storage and variable length strings) cover the breadth of proposals from last time. We may not want to implement all of them in NumPy, but I think we can agree that there are use cases for all them, even if only as external dtypes?

Maybe :-) — but I totally agree that more complete handling of strings should be on the roadmap.

...

Would it help to add "and/or" after the first bullet? Mostly I care about having like to have "improve string dtypes" in some form on the roadmap, and thought it would be helpful to list the concrete proposals that I recall.

Sure, something like and/or that makes it clear that the details are yet to be determined would be great.

...

The actual design choices (especially if we proposal to change any default behavior) will certainly need a NEP.

+1 the roadmap just contains topics/directions of interest. It's not the place for any technical decisions. Related note: we are now using the "wish list" issue label for anything that is too small to put on a roadmap or write a NEP for. Right now there's a lot of random stuff in that label though ([1]), so I think we have to clean that up. Examples of good wish list items that are on there now: - Document API generation with setup.py, genapi.py, etc. (gh-9203) - Feature request: signal broadcasting is OK over core dimension (gh-8811) - Multidimensional fftfreq/rfftfreq (gh-9094) I plan to go through and remove the label from issues that don't fit in the next couple of days. Cheers, Ralf [1] https://github.com/numpy/numpy/issues?q=is%3Aopen+is%3Aissue+label%3A%2223+-...