<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 20, 2014 at 10:12 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"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Mon, Jan 20, 2014 at 10:40 AM, Oscar Benjamin <span dir="ltr"><<a href="mailto:oscar.j.benjamin@gmail.com" target="_blank">oscar.j.benjamin@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Mon, Jan 20, 2014 at 10:00:55AM -0500, Aldcroft, Thomas wrote:<br>
> On Mon, Jan 20, 2014 at 5:11 AM, Oscar Benjamin<br>
> <<a href="mailto:oscar.j.benjamin@gmail.com" target="_blank">oscar.j.benjamin@gmail.com</a>>wrote:<br>
</div><div>> > How significant are the performance issues? Does anyone really use numpy<br>
> > for<br>
> > this kind of text handling? If you really are operating on gigantic text<br>
> > arrays of ascii characters then is it so bad to just use the bytes dtype<br>
> > and<br>
> > handle decoding/encoding at the boundaries? If you're not operating on<br>
> > gigantic text arrays is there really a noticeable problem just using the<br>
> > 'U'<br>
> > dtype?<br>
> ><br>
><br>
> I use numpy for giga-row arrays of short text strings, so memory and<br>
> performance issues are real.<br>
><br>
> As discussed in the previous parent thread, using the bytes dtype is really<br>
> a problem because users of a text array want to do things like filtering<br>
> (`match_rows = text_array == 'match'`), printing, or other manipulations in<br>
> a natural way without having to continually use bytestring literals or<br>
> `.decode('ascii')` everywhere.  I tried converting a few packages while<br>
> leaving the arrays as bytestrings and it just ended up as a very big mess.<br>
><br>
> From my perspective the goal here is to provide a pragmatic way to allow<br>
> numpy-based applications and end users to use python 3.  Something like<br>
> this proposal seems to be the right direction, maybe not pure and perfect<br>
> but a sensible step to get us there given the reality of scientific<br>
> computing.<br>
<br>
</div>I don't really see how writing b'match' instead of 'match' is that big a deal.<br></blockquote><div><br></div></div></div><div>It's a big deal because all your existing python 2 code suddenly breaks on python 3, even after running 2to3.  Yes, you can backfix all the python 2 code and use bytestring literals everywhere, but that is very painful and ugly.  More importantly it's very fiddly because *sometimes* you'll need to use bytestring literals, and *sometimes* not, depending on the exact dataset you've been handed.  That's basically a non-starter.  </div>


<div><br></div><div>As you say below, the only solution is a proper separation of bytes/unicode where everything internally is unicode.  The problem is that the existing 4-byte unicode in numpy is a big performance / memory hit.  It's even trickier because libraries will happily deliver a numpy structured array with an 'S'-dtype field (from a binary dataset on disk), and it's a pain to then convert to 'U' since you need to remake the entire structured array.  With a one-byte unicode the goal would be an in-place update of 'S' to 's'.</div>
<div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And why are you needing to write .decode('ascii') everywhere?</blockquote><div><br></div></div><div>>>> print("The first value is {}".format(bytestring_array[0]))</div><div><br></div><div>On Python 2 this gives "The first value is string_value", while on Python 3 this gives "The first value is b'string_value'".</div>
</div></div></div></blockquote><div><br></div><div>As Nathaniel has mentioned, this is a known problem with Python 3 and the developers are trying to come up with a solution. Python 3.4 solves some existing problems, but this one remains. It's not just numpy here, it's that python itself needs to provide some help.<br>
<br></div><div>Chuck <br></div><br></div></div></div>