<br><br><div><span class="gmail_quote">On 8/24/07, <b class="gmail_sendername">Guido van Rossum</b> &lt;<a href="mailto:guido@python.org">guido@python.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 8/24/07, Thomas Wouters &lt;<a href="mailto:thomas@python.org">thomas@python.org</a>&gt; wrote:<br>&gt; If nobody cares, I will be checking these patches into the trunk this<br>&gt; weekend (after updating them), and then update and check in the rest of the
<br>&gt; p3yk-noslice branch into the py3k branch.<br><br>In the trunk? I&#39;m concerned that that might make it (ever so slightly)<br>incompatible with 2.5, and we&#39;re trying to make it as easy as possible<br>to migrate to 
2.6. Or perhaps you&#39;re just proposing to change the<br>standard builtin types to always use the extended API, without<br>removing the possibility of user types (either in C or in Python)<br>using the simple API, at least in 
2.6?</blockquote><div><br>The changes I uploaded only implement (and in some cases, fix some bugs in) extended slicing support in various builtin types. None of the API changes would be backported (although 2.6 in py3k-warning-mode should obviously tell people to not define __getslice__, and instead accept slice objects in __getitem__. Perhaps even when not in py3k-warnings-mode.)
<br></div><br></div>-- <br>Thomas Wouters &lt;<a href="mailto:thomas@python.org">thomas@python.org</a>&gt;<br><br>Hi! I&#39;m a .signature virus! copy me into your .signature file to help me spread!