[Python-3000-checkins] [Python-3000] r62269 - in python/branches/py3k: Lib/test/test_getargs2.py Objects/abstract.c Python/getargs.c
Thomas Wouters
thomas at python.org
Fri Apr 11 22:49:03 CEST 2008
On Fri, Apr 11, 2008 at 2:53 AM, 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?)
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 <thomas at python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000-checkins/attachments/20080411/ebb7278c/attachment.htm
More information about the Python-3000-checkins
mailing list