<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 24, 2017 at 10:51 AM, Aldcroft, Thomas <span dir="ltr"><<a href="mailto:aldcroft@head.cfa.harvard.edu" target="_blank">aldcroft@head.cfa.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div class="gmail_extra">BTW -- maybe we should keep the pathological use-case in mind: really short strings. I think we are all thinking in terms of longer strings, maybe a name field, where you might assign 32 bytes or so -- then someone has an accented character in their name, and then ge30 or 31 characters -- no big deal.</div></div></div></div></blockquote><div><br></div></span><div><div>I wouldn't call it a pathological use case, it doesn't seem so uncommon to have large datasets of short strings. </div></div></div></div></div></blockquote><div><br></div><div>It's pathological for using a variable-length encoding.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div> I personally deal with a database of hundreds of billions of 2 to 5 character ASCII strings.  This has been a significant blocker to Python 3 adoption in my world.</div></div></div></div></div></blockquote><div><br></div><div>I agree -- it is a VERY common case for scientific data sets. But a one-byte-per-char encoding would handle it nicely, or UCS-4 if you want Unicode. The wasted space is not that big a deal with short strings...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>BTW, for those new to the list or with a short memory, this topic has been discussed fairly extensively at least 3 times before.  Hopefully the *fourth* time will be the charm!<br class="m_-7819779759130024822gmail-Apple-interchange-newline"></div></div></div></div></div></blockquote><div><br></div><div>yes, let's hope so!</div><div><br></div><div>The big difference now is that Julian seems to be committed to actually making it happen!</div><div><br></div><div>Thanks Julian!</div><div><br></div><div>Which brings up a good point -- if you need us to stop the damn bike-shedding so you can get it done -- say so.</div><div><br></div><div>I have strong opinions, but would still rather see any of the ideas on the table implemented than nothing.</div><div><br></div><div>-Chris</div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>