__getslice__ passed INT_MAX rather than sys.maxint for missing endpoint?

"Martin v. Löwis" martin at v.loewis.de
Sun Mar 27 13:10:30 CEST 2005


Dave Huang wrote:
> So, am I misunderstanding things, or is this a doc bug, or a code bug?

Strictly speaking, it is both a doc bug and a code bug.

In CPython, indexes are typically represented internally through C int,
and this is also used to represent the size of the standard containers
(lists, strings, tuples). So "infinity" is appropriately represented
as INT_MAX for such containers.

OTOH, Python int objects are implemented through C longs, so sys.maxint
might be larger if longs are wider than ints. For the indexing issue,
this should be irrelevant: an omitted upper bound should still be the
"infinity" of the index type, so it is a bug when the documentation says
its maxint. However, it is also a bug that the index type is int, as it
should rather be size_t (more precisely, ssize_t). Unfortunately, long
and ssize_t are also of different widths on some platforms.

So I think there should be a sys.maxindex, which is the maximum value
for ssize_t, and that should be the implicit upper bound for getslice,
and the documentation should be fixed accordingly.

For 2.4.x, it is *just* that the documentation should be fixed; the
code needs to stay as it is even though there is no convenient way
to get at the maximum index. Just trying one time at startup would
be the recommended way:

class _GetMaxIndex:
    def __getslice__(self, a, mi):
      import sys
      sys.maxindex = mi
_GetMaxIndex()[:]

Regards,
Martin



More information about the Python-list mailing list