CallPolicy for operators
Hi all Is there a way to apply a CallPolicy to operator definitions? In particular, I'm interested in the inplace operators (+=, -=, *=, /= and friends). To give a bit more context: The library I'm trying to wrap exposes some static const objects. So far, I have been able to wrap modifying function by having a registration facility for these static const objects and a custom CallPolicy that raises an AttributError when one tries to modify one of the registered objects. One option I see is to directly define __iadd__ etc. instead of using the built-in convenience operators. However, I'm not sure whether that has unintended side-effects. I haven't completely understood the operators implementation in bp, but it looks fairly involved. Thanks Michael
On 01/27/2013 05:02 AM, Michael Wild wrote:
Hi all
Is there a way to apply a CallPolicy to operator definitions? In particular, I'm interested in the inplace operators (+=, -=, *=, /= and friends).
To give a bit more context: The library I'm trying to wrap exposes some static const objects. So far, I have been able to wrap modifying function by having a registration facility for these static const objects and a custom CallPolicy that raises an AttributError when one tries to modify one of the registered objects.
One option I see is to directly define __iadd__ etc. instead of using the built-in convenience operators. However, I'm not sure whether that has unintended side-effects. I haven't completely understood the operators implementation in bp, but it looks fairly involved.
I think directly implementing __iadd__ is probably your best bet. I don't think there are any side-effects you need to worry about, but it would probably be a lot of boilerplate. Do make sure you read up on how those methods are supposed to be implemented in pure-Python as regards to handling unexpected types, however, and make sure you follow the same rules in your C++ implementation. Jim
Jim Bosch wrote:
On 01/27/2013 05:02 AM, Michael Wild wrote:
Hi all
Is there a way to apply a CallPolicy to operator definitions? In particular, I'm interested in the inplace operators (+=, -=, *=, /= and friends).
To give a bit more context: The library I'm trying to wrap exposes some static const objects. So far, I have been able to wrap modifying function by having a registration facility for these static const objects and a custom CallPolicy that raises an AttributError when one tries to modify one of the registered objects.
One option I see is to directly define __iadd__ etc. instead of using the built-in convenience operators. However, I'm not sure whether that has unintended side-effects. I haven't completely understood the operators implementation in bp, but it looks fairly involved.
I think directly implementing __iadd__ is probably your best bet. I don't think there are any side-effects you need to worry about, but it would probably be a lot of boilerplate. Do make sure you read up on how those methods are supposed to be implemented in pure-Python as regards to handling unexpected types, however, and make sure you follow the same rules in your C++ implementation.
Jim
I've always used e.g. __iadd__ rather than the convenience stuff. No problems.
On Fri, Mar 15, 2013 at 12:54 PM, Neal Becker <ndbecker2@gmail.com> wrote:
Jim Bosch wrote:
On 01/27/2013 05:02 AM, Michael Wild wrote:
Hi all
Is there a way to apply a CallPolicy to operator definitions? In particular, I'm interested in the inplace operators (+=, -=, *=, /= and friends).
To give a bit more context: The library I'm trying to wrap exposes some static const objects. So far, I have been able to wrap modifying function by having a registration facility for these static const objects and a custom CallPolicy that raises an AttributError when one tries to modify one of the registered objects.
One option I see is to directly define __iadd__ etc. instead of using the built-in convenience operators. However, I'm not sure whether that has unintended side-effects. I haven't completely understood the operators implementation in bp, but it looks fairly involved.
I think directly implementing __iadd__ is probably your best bet. I don't think there are any side-effects you need to worry about, but it would probably be a lot of boilerplate. Do make sure you read up on how those methods are supposed to be implemented in pure-Python as regards to handling unexpected types, however, and make sure you follow the same rules in your C++ implementation.
Jim
I've always used e.g. __iadd__ rather than the convenience stuff. No problems.
Yeah, that's what I've been doing now.
participants (3)
-
Jim Bosch -
Michael Wild -
Neal Becker