<br><br><div class="gmail_quote">On Sun, Mar 16, 2008 at 12:32 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</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;">
On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson<br>
<<a href="mailto:musiccomposition@gmail.com">musiccomposition@gmail.com</a>> wrote:<br>
[Guido]<br>
<div class="Ih2E3d">> > That's a rather long thread. Was any conclusion reached? I'm not sure<br>
> > how introducing a set of aliases will help merging 2.6 code to 3.0.<br>
> > Can you or Christian describe the proposed approach in more detail?<br>
<br>
> As far as I can see, no objections were raised in that thread.<br>
<br>
</div>Hm. I had wanted to register a complaint, but I guess I was too busy.<br>
<div class="Ih2E3d"><br>
> Christian explained the probable approach:<br>
> <a href="http://mail.python.org/pipermail/python-dev/2008-March/077362.html" target="_blank">http://mail.python.org/pipermail/python-dev/2008-March/077362.html</a><br>
<br>
</div>That's not much of a plan. It doesn't discuss any of the effects of<br>
the proposed change on merging code from the 2.6 trunk to the py3k<br>
branch.<br>
<div class="Ih2E3d"><br>
On Sun, Mar 16, 2008 at 12:09 PM, Christian Heimes <<a href="mailto:lists@cheimes.de">lists@cheimes.de</a>> wrote:<br>
> Guido van Rossum wrote:<br>
> > -1. This will make merging code from 2.6 harder, and causes more work<br>
> > for porting C extensions.<br>
><br>
> I'm happy to pay the price for the sake of a clean and easy-to-recall C<br>
> API.<br>
><br>
> The for the C extension problem I already proposed a solution in the<br>
> thread Benjamin mentioned before.<br>
><br>
> #include "Python.h"<br>
> #if PY_VERSION_HEX > 0x03000000<br>
> #include "python2_compat.h"<br>
> #endif<br>
><br>
> Where python2_compat provides aliases for PyInt and PyString:<br>
><br>
> #define PyInt_Spam PyLong_Spam<br>
> ...<br>
> #define PyString_Egg PyBytes_Egg<br>
<br>
</div>So this doesn't address merges at all. Suppose we have some C code<br>
that's shared between 2.6 and 3.0 and manipulates binary data (e.g.<br>
the gzip codec). It currently uses PyString on both branches, so any<br>
changes to the trunk merge smoothly into the py3k branch. But if you<br>
change PyString -> PyBytes in the py3k branch, every change you make<br>
in the 2.6 code will cause a merge conflict. Is that really what you<br>
want? I worry that it will effectively separate the trunk and the py3k<br>
branch, losing the advantage of doing development that effects both at<br>
once.</blockquote><div>We could backport the python2_compact header. <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>
<div><div></div><div class="Wj3C7c"><br>
--<br>
--Guido van Rossum (home page: <a href="http://www.python.org/%7Eguido/" target="_blank">http://www.python.org/~guido/</a>)<br>
</div></div></blockquote></div><br>