On Fri, Apr 11, 2008 at 2:53 AM, Trent Nelson <[EMAIL PROTECTED]> 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?) You keep talking about '%n', but the code is used for Py_BuildValue and PyArg_Parse* and such, not for string formatting (unless you are working to change that for some reason?) The 'n' argument to PyArg_Parse* is meant to be used for indices (like most uses of Py_ssize_t), so the change to PyNumber_Index makes no sense, and the test above is actually broken (IMHO.) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
