On 8/26/07, <b class="gmail_sendername">Travis Oliphant</b> &lt;<a href="mailto:oliphant.travis@ieee.org">oliphant.travis@ieee.org</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Gregory P. Smith wrote:<br>&gt; I&#39;m in favor of not allowing unicode for hash functions.&nbsp;&nbsp;Depending on<br>&gt; the system default encoding for a hash will not be portable.<br>&gt;<br>&gt; another question for hashlib:&nbsp;&nbsp;It uses PyArg_Parse to get a single &#39;s&#39;
<br>&gt; out of an optional parameter [see the code] and I couldn&#39;t figure out<br>&gt; what the best thing to do there was.&nbsp;&nbsp;It just needs a C string to pass<br>&gt; to openssl to lookup a hash function by name.&nbsp;&nbsp;Its C so i doubt it&#39;ll
<br>&gt; ever be anything but ascii.&nbsp;&nbsp;How should that parameter be parsed<br>&gt; instead of the old &#39;s&#39; string format?&nbsp;&nbsp;PyBUF_CHARACTER actually sounds<br>&gt; ideal in that case assuming it guarantees UTF-8 but I wasn&#39;t clear
<br>&gt; that it did that (is it always utf-8 or the possibly useless as far as<br>&gt; APIs expecting C strings are concerned system &quot;default encoding&quot;)?<br>&gt; Requiring a bytes object would also work but I really don&#39;t like the
<br>&gt; idea of users needing to use a specific type for something so simple.<br>&gt; (i consider string constants with their preceding b, r, u, s, type<br>&gt; characters ugly in code without a good reason for them to be there)
<br>&gt;<br><br>The PyBUF_CHARACTER flag was an add-on after I realized that the old<br>buffer API was being in several places to get Unicode objects to encode<br>their data as a string (in the default encoding of the system, I believe).
<br><br>The unicode object is the only one that I know of that actually does<br>something different when it is called with PyBUF_CHARACTER.<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt; Is it just me or do unicode objects supporting the buffer api seem<br>&gt; like an odd concept given that buffer api consumers (rather than<br>&gt; unicode consumers) shouldn&#39;t need to know about encodings of the data
<br>&gt; being received.<br><br>I think you have a point.&nbsp;&nbsp; The buffer API does support the concept of<br>&quot;formats&quot; but not &quot;encodings&quot; so having this PyBUF_CHARACTER flag looks<br>rather like a hack.&nbsp;&nbsp; I&#39;d have to look, because I don&#39;t even remember
<br>what is returned as the &quot;format&quot; from a unicode object if it is<br>requested (it is probably not correct).</blockquote><div><br>given that utf-8 characters are varying widths i don&#39;t see how it could ever practically be correct for unicode.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I would prefer that the notion of encoding a unicode object is separated<br>from the notion of the buffer API, but last week I couldn&#39;t see another
<br>way to un-tease it.<br><br>-Travis</blockquote><div><br>A thought that just occurred to me... Would a PyBUF_CANONICAL flag be useful instead of CHARACTERS?&nbsp; For unicode that&#39;d mean utf-8 (not just the default encoding) but I could imagine other potential uses such as multi-dimension buffers (PIL image objects?) presenting a defined canonical form of the data useful for either serialization and hashing.&nbsp; Any buffer api implementing object would define its own canonical form.
<br></div><br></div>-gps<br><br>