On Thu, Jul 26, 2018 at 12:41 AM, Chris Barker - NOAA Federal < chris.bar...@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+-+Wish+List%22
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
