|
From: Allen B. <al...@vr...> - 2006-07-28 12:20:25
|
It is well known that boost.python can't wrap a method like the one below directly. void getSize(float& width, float& height); To wrap this method a user normally needs to manually write a C++ wrapper method that will call the function and return the values in a boost.python.tuple. This is not difficult to do, but it can get very tedious in a large API. I know there have been discussions about automating this, but has anyone actually written code that will do it. I don't need the code integrated into pyplusplus or anything like that right now, I just want to know if someone has code they are willing to share so I don't have to start from scratch. :) -Allen |
|
From: Matthias B. <ba...@ir...> - 2006-07-28 15:32:02
|
Allen Bierbaum wrote:
> void getSize(float& width, float& height);
>
> To wrap this method a user normally needs to manually write a C++
> wrapper method that will call the function and return the values in a
> boost.python.tuple. This is not difficult to do, but it can get very
> tedious in a large API.
>
> I know there have been discussions about automating this, but has anyone
> actually written code that will do it. I don't need the code integrated
> into pyplusplus or anything like that right now, I just want to know if
> someone has code they are willing to share so I don't have to start from
> scratch. :)
I've implemented something in pypp_api that I called "argument
policies". The code for that is in pypp_api/argpolicy.py (the naming is
somewhat inconsistent because I initially called it "argument
transformers" and the base class for the policies is still called
"ArgTransformerBase").
The argument policies are applied via decoration just as the normal call
policies. In your case, it would be:
cls.Method("getSize").setArgPolicy(Output(1), Output(2))
This specifies that the first and second argument of the method are
actually output values. The Python version of the method will then take
no arguments and return a tuple (width, height).
I have a few "standard" arg policies such as Output, InputArray and
OutputArray that are defined right in argpolicy.py. I've also a few
custom policies in my Maya bindings that do things like checking array
bounds or manipulating those Maya status objects.
Those arg policies are actually just specialized code creators that each
add a block of C++ code before and after the original function/method
invocation. They can also manipulate the argument list and the return value.
Everything is implemented on top of pyplusplus and currently it only
works for methods that don't already create wrappers in pyplusplus. It
would be great if this functionality could eventually moved "down" to
pyplusplus so that the normal wrapper generation also works like this.
This would provide a standard way for a user to inject custom code into
the generated wrappers. I'm currently trying to investigate how this
could be achieved because I want to make some of my wrapped code thread
safe which, I believe, is not possible with the current version of
pyplusplus and pypp_api.
- Matthias -
|
|
From: Allen B. <al...@vr...> - 2006-07-28 15:54:36
|
Matthias Baas wrote:
> Allen Bierbaum wrote:
>
>> void getSize(float& width, float& height);
>>
>> To wrap this method a user normally needs to manually write a C++
>> wrapper method that will call the function and return the values in a
>> boost.python.tuple. This is not difficult to do, but it can get very
>> tedious in a large API.
>>
>> I know there have been discussions about automating this, but has
>> anyone actually written code that will do it. I don't need the code
>> integrated into pyplusplus or anything like that right now, I just
>> want to know if someone has code they are willing to share so I don't
>> have to start from scratch. :)
>
>
> I've implemented something in pypp_api that I called "argument
> policies". The code for that is in pypp_api/argpolicy.py (the naming
> is somewhat inconsistent because I initially called it "argument
> transformers" and the base class for the policies is still called
> "ArgTransformerBase").
>
> The argument policies are applied via decoration just as the normal
> call policies. In your case, it would be:
>
> cls.Method("getSize").setArgPolicy(Output(1), Output(2))
>
> This specifies that the first and second argument of the method are
> actually output values. The Python version of the method will then
> take no arguments and return a tuple (width, height).
>
> I have a few "standard" arg policies such as Output, InputArray and
> OutputArray that are defined right in argpolicy.py. I've also a few
> custom policies in my Maya bindings that do things like checking array
> bounds or manipulating those Maya status objects.
>
> Those arg policies are actually just specialized code creators that
> each add a block of C++ code before and after the original
> function/method invocation. They can also manipulate the argument list
> and the return value.
> Everything is implemented on top of pyplusplus and currently it only
> works for methods that don't already create wrappers in pyplusplus. It
> would be great if this functionality could eventually moved "down" to
> pyplusplus so that the normal wrapper generation also works like this.
> This would provide a standard way for a user to inject custom code
> into the generated wrappers. I'm currently trying to investigate how
> this could be achieved because I want to make some of my wrapped code
> thread safe which, I believe, is not possible with the current version
> of pyplusplus and pypp_api.
This sounds like a great idea. I like the idea of the interface and how
you specify that arguments should be used in what way. Please let me
know if you need help testing or migrating this to Roman's interface in
pyplusplus.
-Allen
>
> - Matthias -
>
|
|
From: Roman Y. <rom...@gm...> - 2006-07-28 19:27:59
|
On 7/28/06, Matthias Baas <ba...@ir...> wrote: >Everything is implemented on top of pyplusplus and currently it only > works for methods that don't already create wrappers in pyplusplus. It > would be great if this functionality could eventually moved "down" to > pyplusplus so that the normal wrapper generation also works like this. It will. I think, that this functionality should be in py++. > This would provide a standard way for a user to inject custom code into > the generated wrappers. Almost right, it will provide a user with full control on generated wrapper code. > I'm currently trying to investigate how this > could be achieved because I want to make some of my wrapped code thread > safe which, I believe, is not possible with the current version of > pyplusplus and pypp_api. True. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Roman Y. <rom...@gm...> - 2006-07-28 19:45:05
|
On 7/28/06, Allen Bierbaum <al...@vr...> wrote:
> This sounds like a great idea. I like the idea of the interface and how
> you specify that arguments should be used in what way. Please let me
> know if you need help testing or migrating this to Roman's interface in
> pyplusplus.
I don't see any problems to add such functionality to py++. But I'd
like to see the
whole picture first:
1. Immutable arguments could be in, out, inout.
2. pointers to fundamental types:
could be arrays with different size policy
3. status as exception
4. custom user policies[ precall, call, postcall ]
4.1 what are performace penalties?
5. what should be done for [pure]virtual functions
6. Another valid question: why do you to insert such functionality into core of
py++? I am not sure that big monolitic core is a good idea. Making py++
better support plug-ins could be a better idea.
Lack of time is the main reason I didn't implement it until now. I
don't have time
to answer all those questions and analize the usecases.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Allen B. <al...@vr...> - 2006-07-28 20:06:19
|
Roman Yakovenko wrote: > On 7/28/06, Allen Bierbaum <al...@vr...> wrote: > >> This sounds like a great idea. I like the idea of the interface and how >> you specify that arguments should be used in what way. Please let me >> know if you need help testing or migrating this to Roman's interface in >> pyplusplus. > > > I don't see any problems to add such functionality to py++. But I'd > like to see the > whole picture first: > 1. Immutable arguments could be in, out, inout. > 2. pointers to fundamental types: > could be arrays with different size policy > 3. status as exception > 4. custom user policies[ precall, call, postcall ] > 4.1 what are performace penalties? > 5. what should be done for [pure]virtual functions > 6. Another valid question: why do you to insert such functionality > into core of > py++? I am not sure that big monolitic core is a good idea. Making py++ > better support plug-ins could be a better idea. I like the idea of option 6. If it was possible to graft on plugins that could add support for this type of thing, it may be possible to keep pyplusplus more modular and understandable. > > Lack of time is the main reason I didn't implement it until now. I > don't have time > to answer all those questions and analize the usecases. > Luckily it looks like Matthias has already taken a look and gotten a pretty useful version working. :) -Allen |
|
From: Matthias B. <ba...@ir...> - 2006-07-29 13:26:37
|
Roman Yakovenko wrote: > I don't see any problems to add such functionality to py++. But I'd > like to see the > whole picture first: > 1. Immutable arguments could be in, out, inout. > 2. pointers to fundamental types: > could be arrays with different size policy > 3. status as exception All of the above is entirely dealt with in the policy object. > 4. custom user policies[ precall, call, postcall ] > 4.1 what are performace penalties? The inserted code is C++ code, so I don't expect any severe performance penalties (it's probably the same code that a user would write when creating the bindings manually). > 5. what should be done for [pure]virtual functions I haven't dealt with this question in pypp_api..... what problems do we have to expect in this case? > 6. Another valid question: why do you to insert such functionality into > core of > py++? I am not sure that big monolitic core is a good idea. Making py++ > better support plug-ins could be a better idea. I don't understand this point. In what way is the current implementation of pyplusplus less monolithic? Isn't it rather the opposite? Currently, the code generated by the calldef code creators is more or less fixed, a user cannot add his own code. Instead, he has to replace the entire code creator object. But if there's a mechanism like the one used for the arg policies in pypp_api you could add your own C++ code (that may be located outside pyplusplus) to the generated function without having to replace the entire function body. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-07-29 18:37:24
|
On 7/29/06, Matthias Baas <ba...@ir...> wrote: > I haven't dealt with this question in pypp_api..... what problems do we > have to expect in this case? We change the signature of the method, it could no be overridden from Python. > > 6. Another valid question: why do you to insert such functionality into > > core of > > py++? I am not sure that big monolitic core is a good idea. Making py++ > > better support plug-ins could be a better idea. > > I don't understand this point. This is just a thought. > In what way is the current implementation > of pyplusplus less monolithic? Isn't it rather the opposite? You are right. The question is whether it should stay to be like this or not. But this question was a theoretical one. > Currently, > the code generated by the calldef code creators is more or less fixed, a > user cannot add his own code. Instead, he has to replace the entire code > creator object. But if there's a mechanism like the one used for the arg > policies in pypp_api you could add your own C++ code (that may be > located outside pyplusplus) to the generated function without having to > replace the entire function body. :-). Before I will start to implement(== to port from pypp_api ) this feature I will write some paper. So anyone( especially you ) can comment it. Wiki could be a good platform to discuss these things, right? -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
