On Wed, May 30, 2012 at 11:42 AM, Antonio Cuni <span dir="ltr"><<a href="mailto:anto.cuni@gmail.com" target="_blank">anto.cuni@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Amaury,<br>
<br>
On 05/30/2012 11:23 AM, Amaury Forgeot d'Arc wrote:<br>
> 2012/5/30 Antonio Cuni <<a href="mailto:anto.cuni@gmail.com">anto.cuni@gmail.com</a> <mailto:<a href="mailto:anto.cuni@gmail.com">anto.cuni@gmail.com</a>>><br>
<div class="im">><br>
> 2) start a completely new repository which contains only the code for py3k.<br>
><br>
><br>
> How is this different from the current py3k branch?<br>
<br>
</div>the difference is that you would get the improvements in translator toolchain<br>
for free. See also my point below.<br>
<div class="im"><br>
> We could also just decide to never merge the default branch,<br>
> or merge only after a release of the main PyPy version.<br>
<br>
</div>possibly, but delaying the merge would make it even more painful. The risk is<br>
that it'll become so painful that nobody will feel like doing it, and thus we<br>
diverge more and more. At the end, we end up with a py3k branch which can't<br>
make use of the cool new features of the JIT/GC/etc. and that will always lack<br>
behind python 2.<br>
<br>
Another point of view is that IMHO porting the changes by doing merges is<br>
harder/more time consuming than porting them by hand.<br>
<div class="HOEnZb"><div class="h5"><br>
ciao,<br>
Anto<br>
_______________________________________________<br>
pypy-dev mailing list<br>
<a href="mailto:pypy-dev@python.org">pypy-dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/pypy-dev" target="_blank">http://mail.python.org/mailman/listinfo/pypy-dev</a><br>
</div></div></blockquote></div><br><div>Hi Anto.</div><div><br></div><div>I think 1) is a no-no for me. This would first mean we have py3k in the default checkout (why???) and also that we need to make sure that py3k tests pass all the time (they don't pass to start with). I don't see this being any beneficial to the current model.</div>
<div><br></div><div>Besidies, this also means we'll never upgrade rpython to py3k (which might be a good thing, just saying). Overall I'm very against pushing *any* burden towards other pypy devs, we have quite enough work. How about you start with detaching interpreter and translation toolchain so those things can leave separately?</div>
<div><br></div><div>Cheers,</div><div>fijal</div>