<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 20, 2014 at 3:35 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jan 20, 2014 at 10:28 PM, Charles R Harris<br>
<div><div><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Jan 20, 2014 at 2:27 PM, Oscar Benjamin <<a href="mailto:oscar.j.benjamin@gmail.com" target="_blank">oscar.j.benjamin@gmail.com</a>><br>
> wrote:<br>
>><br>
>><br>
>> On Jan 20, 2014 8:35 PM, "Charles R Harris" <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>><br>
>> wrote:<br>
>> ><br>
>> > I think we may want something like PEP 393. The S datatype may be the<br>
>> > wrong place to look, we might want a modification of U instead so as to<br>
>> > transparently get the benefit of python strings.<br>
>><br>
>> The approach taken in PEP 393 (the FSR) makes more sense for str than it<br>
>> does for numpy arrays for two reasons: str is immutable and opaque.<br>
>><br>
>> Since str is immutable the maximum code point in the string can be<br>
>> determined once when the string is created before anything else can get a<br>
>> pointer to the string buffer.<br>
>><br>
>> Since it is opaque no one can rightly expect it to expose a particular<br>
>> binary format so it is free to choose without compromising any expected<br>
>> semantics.<br>
>><br>
>> If someone can call buffer on an array then the FSR is a semantic change.<br>
>><br>
>> If a numpy 'U' array used the FSR and consisted only of ASCII characters<br>
>> then it would have a one byte per char buffer. What then happens if you put<br>
>> a higher code point in? The buffer needs to be resized and the data copied<br>
>> over. But then what happens to any buffer objects or array views? They would<br>
>> be pointing at the old buffer from before the resize. Subsequent<br>
>> modifications to the resized array would not show up in other views and vice<br>
>> versa.<br>
>><br>
>> I don't think that this can be done transparently since users of a numpy<br>
>> array need to know about the binary representation. That's why I suggest a<br>
>> dtype that has an encoding. Only in that way can it consistently have both a<br>
>> binary and a text interface.<br>
><br>
><br>
> I didn't say we should change the S type, but that we should have something,<br>
> say 's', that appeared to python as a string. I think if we want transparent<br>
> string interoperability with python together with a compressed<br>
> representation, and I think we need both, we are going to have to deal with<br>
> the difficulties of utf-8. That means raising errors if the string doesn't<br>
> fit in the allotted size, etc. Mind, this is a workaround for the mass of<br>
> ascii data that is already out there, not a substitute for 'U'.<br>
<br>
</div></div>If we're going to be taking that much trouble, I'd suggest going ahead<br>
and adding a variable-length string type (where the array itself<br>
contains a pointer to a lookaside buffer, maybe with an optimization<br>
for stashing short strings directly). The fixed-length requirement is<br>
pretty onerous for lots of applications (e.g., pandas always uses<br>
dtype="O" for strings -- and that might be a good workaround for some<br>
people in this thread for now). The use of a lookaside buffer would<br>
also make it practical to resize the buffer when the maximum code<br>
point changed, for that matter...<br>
<br>
Though, IMO any new dtype here would need a cleanup of the dtype code<br>
first so that it doesn't require yet more massive special cases all<br>
over umath.so.<br></blockquote><div><br></div><div>Worth thinking about. As another alternative, what is the minimum we need to make a restricted encoding, say latin-1, appear transparently as a unicode string to python? I know the python folks don't like this much, but I suspect something along that line will eventually be required for the http folks. <br>
<br></div><div>Chuck<br>
</div></div></div></div>