<br><br><div class="gmail_quote">On Mon, Jun 2, 2008 at 5:33 AM, M.-A. Lemburg <<a href="mailto:mal@egenix.com">mal@egenix.com</a>> wrote:<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;"><div><div class="Wj3C7c"><br>
Okay, how about this? <a href="http://codereview.appspot.com/1521" target="_blank">http://codereview.appspot.com/1521</a><br>
<br>
Using that patch, both PyString_ and PyBytes_ APIs are available using<br>
function stubs similar to the above. I opted to define the stub<br>
functions right next to the ones they were stubbing rather than<br>
putting them all at the end of the file or in another file but they<br>
could be moved if someone doesn't like them that way.<br>
</div></div></blockquote>
<br>
Thanks. I was working on a similar patch. Looks like you beat<br>
me to it.<br>
<br>
The only thing I'm not sure about is having the wrappers in the<br>
same file - this is likely to cause merge conflicts when doing<br>
direct merging and even with an automated renaming approach,<br>
the extra code would be easier to remove if it were e.g. at<br>
the end of the file or even better: in a separate file.<br>
<br>
My patch worked slightly differently: it adds wrappers PyString*<br>
that forward calls to the PyBytes* APIs and they all live in<br>
stringobject.c. stringobject.h then also provides aliases<br>
so that recompiled extensions pick up the new API names.<br>
<br>
While working on my patch I ran into an issue that I haven't<br>
been able to resolve: the wrapper functions got optimized away<br>
by the linker and even though they appear in the libpython2.6.a,<br>
they don't end up in the python binary itself.<br>
<br>
As a result, importing Python 2.5 in the resulting 2.6<br>
binary still fails with a unresolved PyString symbol.<br>
<br>
Please check whether that's the case for your patch as well.</blockquote><div class="Ih2E3d"><br>I think that is going to happen no matter which approach is used (yours or mine) unless we force some included code to call each of the stubs (needlessly inefficient). One way to do that is to reference them all from a section of code called conditionally based upon an always false condition that the compiler and linker can never predetermine is false so that it cannot be eliminated as dead code.<br>
<br>Given that, should we bother? I don't think we really need PyBytes_ to show up in the binary ABI for 2.x even if that is how we write the calls in the python internals code. The arguments put forth that debugging is easier if you can just set a breakpoint on what you read may be true but including stub functions doesn't help this when most of the time they're compiled under the alternate name using #defines so a breakpoint set on the stub name will not actually trigger.<br>
<br>API wise we're really providing the PyBytes* names to make module author's work of writing code that targets 2.6 and 3.x easier but isn't it reasonable for authors to just be told that they're just #defined aliases for PyString*. There is no goal, nor should there be, of a module binary compiled against 2.x loading and working in 3.x.<br>
<br>I expect most module authors, code generators and such will want to target Python 2.x earlier than 2.6 as well so should we provide PyBytes_ names as a public API in 2.6 at all? (regardless of if we use the PyBytes names internally for any reason)<br>
<br>-gps<br><br></div></div>