<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 15, 2014 at 10:27 AM, Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</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="im">On Wed, Jan 15, 2014 at 4:38 AM, Julian Taylor <span dir="ltr"><<a href="mailto:jtaylor.debian@googlemail.com" target="_blank">jtaylor.debian@googlemail.com</a>></span> wrote:<br>
</div><div class="gmail_extra">

<div class="gmail_quote"><div class="im"><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>>     I try to print my fileContent array after I read it and it looks<br>


</div><div>
>     like this :<br>
><br>
>     ["b'C:\\\\Users\\\\Documents\\\\Project\\\\mytextfile1.txt'"<br>
>       "b'C:\\\\Users\\\\Documents\\\\Project\\\\mytextfile2.txt'"<br>
>       "b'C:\\\\Users\\\\Documents\\\\Project\\\\mytextfile3.txt'"]</div></blockquote><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">


<div>you have the bytes representation and a duplicate slash in it.<br></div>
</blockquote><div><br></div><div>the duplicate slash confuses me, but I'm not running py3 to test, so...</div><div class="im"><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">


np.loadtxt(file, dtype=bytes).astype(str)<br>
<br>
for non ascii I guess you should use python directly as numpy would also<br>
require a python loop with explicit decoding.<br><br>
Currently handling strings in python3 with numpy is even worse than<br>
before, you always have to go over bytes and do explicit decodes to get<br>
python strings out of ascii data.<br></blockquote><div><br></div></div><div>There is a MASSIVE set of threads on Python-dev about better support for ASCII and ASCII+binary data in py3 -- but in the meantime, I think we have two issue shere that could be adressed:</div>


<div><br></div><div>1) loadtext behavior -- it's a really, really common case for  data files suitable for loadtxt to be ascii, but they also could be another encoding -- so loadtext should have the option to specify the encoding (default to ascii? or ascii-compatible?)</div>


<div><br></div><div>The trick here is handling both these cases correctly -- clearly loadtxt is broken on py3 now. This example works fine under py2.</div><div><br></div><div>It seems to be reading the file as bytes, then passing those bytes off to a unicode string (str in py3), without specifying an encoding (which I think is how that b' ...'</div>


<div> junk gets in there.</div><div><br></div><div>note that: np.loadtxt('pathlist.txt', dtype=unicode) works fine on py2 as well:</div><div><br></div><div><div>In [7]: np.loadtxt('pathlist.txt', dtype=unicode)</div>


<div>Out[7]: </div><div>array([u'C:\\Users\\Documents\\Project\\mytextfile1.txt',</div><div>       u'C:\\Users\\Documents\\Project\\mytextfile2.txt',</div><div>       u'C:\\Users\\Documents\\Project\\mytextfile3.txt'], </div>


<div>      dtype='<U42')</div><div><br></div><div>which is what should happen in py3. So the internal loadtxt code must be confusing bytes and unicode objects...</div><div><br></div></div><div>Anyway, this should work, and there should be an obvious way to spell it.</div>


<div><br></div><div>2) numpy string types -- it seems numpy already has a both a string type and unicode type -- perhaps some re-naming or better documentation is in order:</div><div>   the string type 'S10', for example, should be clearly defined as 1-byte per character ascii-compatible.</div>


<div><br></div><div>I'm not sure how many bytes the unicode type has, but it may make sense to be abel to choose UCS-2 or UCS-4 -- though memory is cheep, I'd probably go with UCS-4 and be done with it.</div></div>
</div></div></blockquote><div><br></div><div>There was a discussion of this long ago and UCS-4 was chosen as the numpy standard. There are just too many complications that arise in supporting both.<br><br></div><div>Chuck <br>
</div><br></div></div></div>