> 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. Then that will be the place to hash out the details — perfect. I just got a little concerned that s not-well vetted solution was getting nailed down in the roadmap. -CHB _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
