<div dir="ltr">2013/8/1 Peter FELECAN <span dir="ltr"><<a href="mailto:pfelecan@opencsw.org" target="_blank">pfelecan@opencsw.org</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">Yann Rouillard <<a href="mailto:yann@pleiades.fr.eu.org">yann@pleiades.fr.eu.org</a>> writes:<br>><br><span style="color:rgb(34,34,34)">What people need to understand is that a 2.6 non binary module can be</span><br>

</div></div>
run by a 2.7 interpreter. The reverse is not always true. This is why I<br>
proposed to replace 2.6 by 2.7 in our next transition from unstable to a<br>
named catalog.<br></blockquote><div><br></div><div style>I thought Maciej provided a counter-example with the range function where python 2.7 didn't run the code whereas python 2.6 worked. I may have missed something in this long thread, wasn't the example valid ?</div>

<div style><br></div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This is not to be confused with the major incompatibilities between 2.x<br>
and 3.x where using a different prefix is required.<br></blockquote><div><br></div><div style>To keep thing consistent, I would prefer to have a CSWpy27- prefix if we have a CSWpy3- our CSWpy33- prefix.</div><div style>This way the user will not install a CSWpy- package while looking for a module for python 3.</div>

<div style><br></div><div style>Yann</div><div style><br></div></div></div></div>