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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Wouters
Sent: 11 April 2008 21:49
To: Trent Nelson
Cc: Amaury Forgeot d'Arc; [EMAIL PROTECTED]; 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 <[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
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
