[Python-3000] [Python-3000-checkins] r62269 - in python/branches/py3k: Lib/test/test_getargs2.py Objects/abstract.c Python/getargs.c

[Guido van Rossum]

I think you're right, the whole thing ought to be rolled back. The
whole point of __index__ was that __int__ cannot be trusted not to
truncate floats or float-like types. (Or do other conversions e.g.
from string.)

On Thu, Apr 10, 2008 at 5:53 PM, Trent Nelson <tnelson at onresolve.com> wrote:
> > > Does this mean that floats can now be used as list indexes?
>  > > Preventing this was the motivation for introducing the nb_index slot.
>  >
>
> > > from http://www.python.org/dev/peps/pep-0357 ::
>  > >
>  > >     The biggest example of why using nb_int would be a bad
>  > >     thing is that float objects already define the nb_int method, but
>  > >     float objects *should not* be used as indexes in a sequence.
>
>
> > It sure did!  At least, between r62269 and r62279 ;-)  Ben pointed out
>  > my error, which I fixed in r62280.
>  >
>  >         Trent.
>
>  Hrrm.  I just re-read that PEP.  This stuck out:
>
>     It is not possible to use the nb_int (and __int__ special method)
>     for this purpose because that method is used to *coerce* objects
>     to integers.  It would be inappropriate to allow every object that
>     can be coerced to an integer to be used as an integer everywhere
>     Python expects a true integer.  For example, if __int__ were used
>     to convert an object to an integer in slicing, then float objects
>     would be allowed in slicing and x[3.2:5.8] would not raise an error
>     as it should.
>
>  I think I've pretty much violated the first few sentences with my change to PyNumber_Index().  Even with the change in r62280 which checks that we're not dealing with a float, it's still permitting anything else with an __int__ representation to pass through just fine.
>
>  Note that all of this originated from the following in test_args2:
>
>  class Long:
>
>     def __int__(self):
>         return 99
>
>  class Signed_TestCase(unittest.TestCase):
>     ...
>     def test_n(self):
>         ...
>         self.failUnlessEqual(99, getargs_n(Long()))
>
>  Before the change, %n was passing through to %l unless sizeof(long) != sizeof(size_t) (in convertsimple() -- Python/getargs.c).  Windows x64 is the only platform where this assertion holds true, which drew my attention to the problem.
>
>  The PEP's take on the situation would be that sequence[Long()] should fail (which isn't currently the case with my latest PyNumber_Index() changes).  If we want to adhere to the behaviour prescribed in the PEP, then it seems like PyNumber_Index() should be reverted back to its original state, and the handling of %n in convertsimple() should be be done without calling PyNumber_Index().
>
>  (I assume we *do* want to support `'%n' % Long()` though right, or should the test be done away with?)
>
>  Note that there's all sorts of problems with PyLong_AsSize_t() on Windows x64 when it comes to handling numbers close, equal or surpassing negative maximums.  (See first posting to issue 2440 for examples.)
>
>
>
>
>         Trent.
>  _______________________________________________
>  Python-3000-checkins mailing list
>  Python-3000-checkins at python.org
>  http://mail.python.org/mailman/listinfo/python-3000-checkins
>



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