[Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation

Guido van Rossum guido at python.org
Thu Feb 9 23:42:15 CET 2006


On 2/9/06, Adam Olsen <rhamph at gmail.com> wrote:
> On 2/9/06, Travis Oliphant <oliphant.travis at ieee.org> wrote:
> >
> > Guido seemed accepting to this idea about 9 months ago when I spoke to
> > him.  I finally got around to writing up the PEP.   I'd really like to
> > get this into Python 2.5 if possible.
>
> -1
>
> I've detailed my reasons here:
> http://mail.python.org/pipermail/python-dev/2006-January/059851.html

I don't actually see anything relevant to this discussion in that post.

> In short, there are purely math usages that want to convert to int
> while raising exceptions from inexact results.  The name __index__
> seems inappropriate for this, and I feel it would be cleaner to fix
> float.__int__ to raise exceptions from inexact results (after a
> suitable warning period and with a trunc() function added to math.)

Maybe cleaner, but a thousand time harder given the status quo. Travis
has a need for this *today* and __index__ can be added without any
incompatibilities. I'm not even sure that it's worth changing __int__
for Python 3.0.

Even if float.__int__ raised an exception if the float isn't exactly
an integer, I still think it's wrong to use it here. Suppose I naively
write some floating point code that usually (or with sufficiently
lucky inputs) produces exact results, but which can produce inaccurate
(or at least approximate) results in general. If I use such a result
as an index, your proposal would allow that -- but the program would
suddenly crash with an ImpreciseConversionError exception if the
inputs produced an approximated result. I'd rather be made aware of
this problem on the first run. Then I can decide whether to use int()
or int(round()) or whatever other appropriate conversion.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list