[Numpy-discussion] Roadmap proposal, v3
ralf.gommers at gmail.com
Thu Jul 26 00:19:12 EDT 2018
On Thu, Jul 26, 2018 at 12:41 AM, Chris Barker - NOAA Federal <
chris.barker at 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 (), 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion