<br><br><div class="gmail_quote">On Tue, Jul 27, 2010 at 11:34 AM, Fernando Perez <span dir="ltr">&lt;<a href="http://fperez.net">fperez.net</a>@<a href="http://gmail.com">gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Jul 27, 2010 at 11:14 AM, Brian Granger &lt;<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Yes, I hadn&#39;t though about the fact that unicode objects are buffers as<br>
&gt; well.  But, we could raise a TypeError when a user tries to send a unicode<br>
&gt; object (str in python 3).  IOW, don&#39;t treat unicode as buffers and force<br>
&gt; them to encode/de ode.  Does this make sense or should we allow unicode to<br>
&gt; be sent as buffers.<br>
<br>
</div>Well, the problem I explained about a possible mismatch in internal<br>
unicode storage format rears its ugly head if we allow<br>
unicode-as-buffer.  I was precisely worried about sending 3.x strings<br>
as buffers, since the two ends may not agree on what the buffer means.<br>
 I may be worrying about a non-problem, but at some point it might be<br>
worth veryfing this.  The test is a bit cumbersome to set up, because<br>
you have to build two versions of Python, one with ucs-2 and one with<br>
ucs-4, and see what happens if they try to send each other stuff.  But<br>
I think it&#39;s a test worth making, so we know for sure whether this is<br>
a problem or not, as it will dictate design decisions for 3.x on all<br>
string handling.<br>
<br></blockquote><div><br></div><div>This is definitely an issue.  Also, someone could set their own custom unicode encoding by hand and that would mess this up as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

If it is a problem, then there are some options:<br>
<br>
- disallow communication between ucs 2/4 pythons.<br></blockquote><div><br></div><div>But this doesn&#39;t account for other encoding/decoding setups.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

- detect a mismatch and encode/decode all unicode strings to utf-8 on<br>
send/receive, but allow raw buffer sending if there&#39;s no mismatch.<br>
</blockquote><div><br></div><div>This will be tough though if users set their own encoding.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">- *always* encode/decode.<br>

<br></blockquote><div><br></div><div>I think this is the option that I prefer (having users to this in their application code).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

The middle option seems appealing because it avoids the overhead of<br>
encoding/decoding on all sends, but I&#39;m worried it may be too brittle.<br>
<br></blockquote><div><br></div><div>Brian</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Cheers,<br>
<font color="#888888"><br>
<br>
f<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Brian E. Granger, Ph.D.<br>Assistant Professor of Physics<br>Cal Poly State University, San Luis Obispo<br><a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a><br>
<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>