<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jul 25, 2018 at 4:02 PM Stefan van der Walt <<a href="mailto:stefanv@berkeley.edu">stefanv@berkeley.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chris,<br>
<br>
On Wed, 25 Jul 2018 08:13:26 -0700, Chris Barker - NOAA Federal wrote:<br>
> For example, I am very wary of putting a non-fixed width encoding (e.g.<br>
> Utf-8) in a fixed width field.<br>
> <br>
> But this PR is not the place to discuss that.<br>
<br>
Since you've followed that discussion closely, can you push a commit to<br>
my PR with text that more accurately captures the situation?<br>
<br>
Thanks!<br>
Stéfan<br></blockquote><div><br></div><div>Hi Chris,</div><div><br></div><div>Obviously the string dtype proposal in the roadmap is only a sketch at this point :).</div><div><br></div><div>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?</div><div><br></div><div>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. The actual design choices (especially if we proposal to change any default behavior) will certainly need a NEP.</div><div><br></div><div>Best,</div><div>Stephan</div></div></div>