Negative array indicies and slice()

Ian Kelly ian.g.kelly at gmail.com
Thu Nov 1 20:07:32 CET 2012


On Thu, Nov 1, 2012 at 5:32 AM, Andrew Robinson
<andrew3 at 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.


More information about the Python-list mailing list