Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-11 08:42:31


Hi Scott,

This is fantastic! I'm applying your patch. Did you consider extending the
automatic wrapping feature to support your inplace operators? It seems like
an obvious step.

> I also fixed a problem with the inplace power operator. I call attention
> to this because i think the same problem is also present in the existing
> non-inplace version, from which i copied it.
>
> We have the following in classes.cpp:
>
> PyObject* instance::power(PyObject* exponent, PyObject* modulus)
> {
> if (as_object(modulus->ob_type) == Py_None)
> return callback<PyObject*>::call_method(this, "__pow__",
exponent);
> else
> return callback<PyObject*>::call_method(this, "__pow__", exponent,
modulus);
> }
>
> When the ordinary (2-arg) version of power is used, `modulus' is Py_None.
> But `as_object(Py_None->ob_type)' is not Py_None --- the type of None
> isn't None. I think that the test should be written as just
>
> if (modulus == Py_None)
>
> (since there's only one None object).
>
> Before i made that change for the inplace version, i was getting
> errors about passing the wrong number of arguments.

I think you're right. Would you care to add tests which confirm the original
bug and send it in a patch with the fix?

> The diffs (against the current cvs) follow.
> If this looks ok, i'll move on to the other two patches.

I think I should explain why I'm asking you to do so much work here ;-)

I am currently re-constructing Boost.Python. I am working with a new system
for doing translation between C++ and Python data types; one which will
reduce the size of compiled modules and enable cross-module inheritance. I
thought I was going to be able to migrate in small steps, but it looks like
that would be really difficult. My plan as of now is to work with
Python2.2b2 sources, which will allow me to throw away most of the existing
code for implementing extension classes. I am telling you this in case you
want to adjust what you're working on, since some part of the code will
undoubtedly go away or change. If you would like to be part of this
development effort, I would be more than happy to deal you in.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk