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.