<br><br><div class="gmail_quote">On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg &lt;<a href="mailto:mal@egenix.com" target="_blank">mal@egenix.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>On 2008-06-03 01:29, Gregory P. Smith wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum &lt;<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>&gt; wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I will freely admit that I haven&#39;t followed this thread in any detail,<br>
but if it were up to me, I&#39;d have the 2.6 internal code use PyString<br>
</blockquote>
<br>
...<br>
<br>
Should we read this as a BDFL pronouncement and make it so?<br>
<br>
All that would mean change wise is that trunk r63675 as well as possibly<br>
r63672 and r63677 would need to be rolled back and this whole discussion<br>
over if such a big change should have happened would turn into a moot point.<br>
</blockquote>
<br></div>
I would certainly welcome reverting the change.<br>
<br>
All that&#39;s needed to support PyBytes API in 2.x is a set of #defines<br>
that map the new APIs to the PyString names. That&#39;s a clean and<br>
easily understandable solution.<br>
</blockquote><div><br>Okay, I&#39;ve reverted r63675 in trunk revision r64048.&nbsp; That leaves all of the python modules and internals using PyString_ api names instead of PyBytes_ api names as they were before.&nbsp; PyBytes_ #define&#39;s exist for the appropriate PyString methods incase anyone wants to use those.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Programmers interested in the code<br>
for a PyString API can then still look up the code in stringobject.c,<br>
e.g. to find out how a certain special case is handled or to check<br>
the ref counting - just like they did for years.</blockquote><div><br>The files still exist with the new names.&nbsp; bytesobject.c instead of stringobject.c.&nbsp; Those renames were done in the other CLs i mentioned which have not yet been reverted.&nbsp; The current state seems a bit odd because they depend on the #defines to cause method definitions to be the PyString_ names instead of the PyBytes_ names.<br>
&nbsp;<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Developer who want to start differentiating between mixed byte/text<br>
data and bytes-only can start using PyBytes for byte data.<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


I would also add macros that map the PyBytes_* APIs to PyString_*, but<br>
I would not start using these internally except in code newly written<br>
for 2.6 and intended to be &quot;in the spirit of 3.0&quot;. IOW use PyString<br>
for 8-bit strings containing text, and PyBytes for 8-bit strings<br>
containing binary data. For 8-bit strings that could contain either<br>
text or data, I&#39;d use PyString, in the spirit of 2.x.<br>
</blockquote></blockquote>
<br></div></blockquote></div><br>