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

[Trent Nelson]

Agreed, in the middle of reverting the changes made in 62269 and 62279 now.  I've also figured out why getargs_n() is broken for Windows x64 for negative values.  I'll post a patch for review to python-3000@ shortly.


________________________________

        From: thomaswout at gmail.com [mailto:thomaswout at gmail.com] On Behalf Of Thomas Wouters
        Sent: 11 April 2008 21:49
        To: Trent Nelson
        Cc: Amaury Forgeot d'Arc; python-3000-checkins at python.org; Python 3000
        Subject: Re: [Python-3000] [Python-3000-checkins] r62269 - in python/branches/py3k: Lib/test/test_getargs2.py Objects/abstract.c Python/getargs.c




        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!