<br><br><div><span class="gmail_quote">On 8/24/07, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> 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 <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:<br>> If nobody cares, I will be checking these patches into the trunk this<br>> weekend (after updating them), and then update and check in the rest of the
<br>> p3yk-noslice branch into the py3k branch.<br><br>In the trunk? I'm concerned that that might make it (ever so slightly)<br>incompatible with 2.5, and we're trying to make it as easy as possible<br>to migrate to
2.6. Or perhaps you'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 <<a href="mailto:email@example.com">firstname.lastname@example.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!