[Travis] > > > Would it be possible to change > > > > > > _PyEval_SliceIndex in ceval.c > > > > > > so that rather than throwing an error if the indexing object is not an > > > integer, the code first checks to see if the object has a > > > tp_as_number->nb_int method and calls it instead.
[Guido] > > I don't think this is the right solution; since float has that method, > > it would allow floats to be used as slice indices, but that's not > > supposed to work (to protect yourself against irreproducible results > > due to rounding errors). [David] > I wonder if floats are the special case here, not "integer like objects". > > I've never been particularly happy about the confusion between the two > roles of int() and it's C equivalents, i.e. casting and conversion. You're right, that's the crux of the matter; I unfortunately copied a design mistake from C here. In Python 3000 I'd like to change this so that floats have a __trunc__() method to return an integer (invokable via trunc(x)). But in Python 2.x, we can't be sure that floats are the *only* exception -- surely people who are implementing their own "float-like" classes are copying float's example and implementing __int__ to mean the same thing. For example, the new decimal class in Python 2.4 has a converting/truncating __int__ method. (And despite being decimal, it's no less approximate than float; decimal is *not* an exact numerical type.) So I still think it's unsafe (in Python 2.x) to accept __int__ in the way Travis proposes. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
