On Thu, Jul 26, 2018 at 12:41 AM, Chris Barker - NOAA Federal < email@example.com> 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 (), 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.