Re: [pygccxml-development] argument policies

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
>> One thing that might be useful for me at the moment would be the
>> possibility for an arg policy to actually spawn another wrapper so that
>> there'll be two wrappers with different signatures.
> 
> I think a little bit different. I think that pyplusplus should
> generate only 1 wrapper
> for the function. But it should be fully functional. All other
> customization/conveniences should be done from Python.
> 
> For example "return status as exception" arg policies could be solved in 
> Python.

But then it would only work on classes instantiated from Python and not 
on classes returned from wrapped C++ functions. So it's not equivalent 
to implementing the above right inside the C++ wrappers.

>> For example, I have
>> C++ methods that look like this:
>>
>>    void get(double*)
>>
>> They just return an array of a predefined size. With my current arg
>> policies I can turn that into a Python method that takes no arguments
>> and returns a list of floats. But meanwhile I'm also toying with the
>> idea to provide an additional version of the method that takes a list as
>> argument and that will fill that list with the return values. This will
>> be less "Pythonic" but it's closer to the original C++ API.
>> I don't know if it should really be the arg policy that creates the
>> additional wrapper or if it should be done by the user. For example, I
>> could also imagine a way where the user can "clone" a declaration and
>> then just apply a different arg policy to the clone.
> 
> This will never work ( reliably ). py++ assumes that code is 100% correct.

I don't understand those two sentences. What exactly are you referring 
to that will never work? And which code is not correct?

> Another way to solve this is to parse files, generate C++ wrapper for
> the functions,
> and then to parse again with generated functions wrappers.

But all the information is already there after one parsing step, so why 
is it better to do another pass?

>> > Yes. If you don't mind I'd like next structure of the directory:
>> > contrib
>> > |----your name
>>
>> Do you really insist on this? What name would that be? The experimental
>> stuff is not by myself alone, it's also by Allen. Personally, I would
>> much prefer a directory name that's chosen after the *functionality* of
>> its contents and not after its initial author(s). The latter would
>> rather look as if the directory contains my private stuff, but of
>> course, the directory is open to anyone and people should rather be
>> encouraged to contribute to it (would we then have to rename the
>> directory? ;) The authors can be mentioned in a file inside the
>> directory, then it will also be clear that you are not responsible for
>> that code and the list of authors can be extended if necessary.
> 
> I don't insist on this at all. I saw this structure in docutils
> project. If you have
> something different in mind, that is perfectly okay with me.

I just would have put the stuff from the experimental directory into 
"contrib/pypp_api" and the array stuff in, say, "contrib/arrayinfo"...

- Matthias -