<div dir="ltr">On Thu, Jan 23, 2014 at 12:10 PM, <span dir="ltr"><<a href="mailto:josef.pktd@gmail.com" target="_blank">josef.pktd@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> Exactly -- but what should those conversion/casting rules be? We can't<br>
> decide that unless we decide if 'S' is for text or for arbitrary bytes -- it<br>
> can't be both. I say text, that's what it's mostly trying to do already. But<br>
> if it's bytes, fine, then some things still need cleaning up, and we could<br>
> really use a one-byte-text type. and if it's text, then we may need a bytes<br>
> dtype.<br>
<br>
</div>(remember I'm just a balcony muppet)<br></blockquote><div><br></div><div style>me too ;-) </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
As far as I understand all codecs have the same ascii part. </blockquote><div><br></div><div style>nope -- certainly not multi-byte codecs. And one of the key points of utf-8 is that the ascii part is compatible -- none of teh other full-unicode encoding are.</div>
<div style><br></div><div style>many of the one-byte-per-char ones do share the ascii part, but not all, or not completely.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So I would<br>
cast on ascii and raise on anything else.<br></blockquote><div><br></div><div style>still a fine option -- clearly defined and quite useful for scientific text. However, I would prefer latin-1 -- that way you might get garbage for the non-ascii parts, but it wouldn't raise an exception and it round-trips through encoding/decoding. And you would have a somewhat more useful subset -- including the latin-language character and symbols like the degree symbol, etc.</div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
or follow whatever the convention of numpy is:<br>
<br>
>>> s = -256<br>
>>> np.array((s,), dtype=np.uint8)[0] == s<br>
False<br>
>>> s = -1<br>
>>> np.array((s,), dtype=np.uint8)[0] == s<br>
False<br></blockquote><div><br></div><div style>I think text is distinct enough from numbers that we don't need to do that same thing -- and this is result of well-defined casting rules built into the compiler (and hardware?) for the numeric types. I dont hink we have either the standard or compiler support for text conversions like that.</div>
<div style><br></div><div style>-CHB</div><div style><br></div><div style>PS: this is interesting, on py2:</div><div style><br></div><div style><br></div><div style><div>In [176]: a = np.array((2222,), dtype='S')</div>
<div><br></div><div>In [177]: a</div><div>Out[177]: </div><div>array(['2'], </div><div> dtype='|S1')</div><div><br></div><div style>It converts it to a string, but only grabs the first character? (is it determining the size before converting to a string?</div>
<div style><br></div><div style>and this:</div><div style><br></div><div style><div>In [182]: a = np.array(2222, dtype='S')</div><div><br></div><div>In [183]: a</div><div>Out[183]: </div><div>array('2222', </div>
<div> dtype='|S24')</div><div><br></div></div><div style>24 ? where did that come from?</div><div style><br></div><div style><br></div></div><div style><br></div><div style><br></div><div style><br></div><div style>
<br></div><div style><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Josef<br>
<div class="im"><br>
><br>
> Key here is that we don't have the option of not breaking anything, because<br>
> there is a lot already broken.<br>
><br>
> -Chris<br>
><br>
><br>
> --<br>
><br>
> Christopher Barker, Ph.D.<br>
> Oceanographer<br>
><br>
> Emergency Response Division<br>
> NOAA/NOS/OR&R <a href="tel:%28206%29%20526-6959" value="+12065266959">(206) 526-6959</a> voice<br>
> 7600 Sand Point Way NE <a href="tel:%28206%29%20526-6329" value="+12065266329">(206) 526-6329</a> fax<br>
> Seattle, WA 98115 <a href="tel:%28206%29%20526-6317" value="+12065266317">(206) 526-6317</a> main reception<br>
><br>
> <a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a><br>
><br>
</div><div class=""><div class="h5">> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
><br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><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>