On Thu, Nov 1, 2012 at 5:32 AM, Andrew Robinson <andr...@r3dsolutions.com> wrote: > Hmmmm.... was that PEP the active state of Python, when Tim rejected the bug > report?
Yes. The PEP was accepted and committed in March 2006 for release in Python 2.5. The bug report is from June 2006 has a version classification of Python 2.5, although 2.5 was not actually released until September 2006. > Pep 357 merely added cruft with index(), but really solved nothing. > Everything index() does could be implemented in __getitem__ and usually is. No. There is a significant difference between implementing this on the container versus implementing it on the indexes. Ethan implemented his string-based slicing on the container, because the behavior he wanted was specific to the container type, not the index type. Custom index types like numpy integers on the other hand implement __index__ on the index type, because they apply to all sequences, not specific containers. This must be separate from standard int conversion, because standard int conversion is too general for indexing. > slice is also a full blown object, which implements a trivial method to dump > the contents of itself to a tuple. slice.indices() does not trivially dump its contents as given. It takes a sequence length and adjusts its indices to that length. The C implementation of this is around 60 lines of code. > Don't bother to fix the bug; allow Python to crash with a subtle bug that > often take weeks to track down by the very small minority doing strange > things (Equivalent to the "monkey patch" syndrome of D'Aprano; BTW: The > longer the bug is left unfixed, the more people will invent "uses" for it ) It's been 6 years already. AFAIK nobody has invented any uses that are actually at risk of invoking the GC bug. -- http://mail.python.org/mailman/listinfo/python-list
